SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (6 de 6)

CONCLUSIONES

********************
Índice
Parte 1
Parte 2
Parte 3
Parte 4
Parte 5
Parte 6
********************

Los profesionales de la seguridad de lado de los buenos, y que se dediquen a ello, tienen sólo unos meses para descubrir y desvelar tantas vulnerabilidades como les sea posible para que Microsoft las solucione.

Finalizado el período de soporte extendido, sólo les quedará el recurso de hacer tanto ruido como sea posible para ver si con ello se logra forzar que, ante la demanda social, se publiquen parches de seguridad de forma esporádica y para determinados problemas. Magra posibilidad.

Por contra, habrá ciberdelincuentes, ciberjércitos y agencias y organizaciones varias que tratarán de hacer justo lo contrario: ser lo más discretos posibles para que sus "armas" se mantengan en secreto y sigan funcionando para ellos el mayor tiempo posible.

Todo ello mientras sigan existiendo numerosos equipos con Windows XP en todo tipo de redes: domésticas, privadas, gubernamentales,...

Y, aunque se salga un poco del tema de este post, todo ello me hace pensar en otra versión de Windows que a no mucho tardar (en 2.015) dejará de tener soporte: Windows Server 2003. Un sistema operativo para servidores, lo cual da que pensar.

Por un lado, los servidores suelen ser máquinas mucho más críticos y resistentes que los ordenadores personales. Tienen una vida útil más larga. Quien espere a que se rompa el ordenador para cambiar el sistema operativo tendrá 2003 Server para rato.

Por otro, los servidores pueden soportar aplicaciones críticas para las organizaciones. Y si alguna de ellas no fuera soportada por las versiones más modernas de Windows Server... no faltará quien piense en quedarse como está. Al fin y al cabo, modificar la infraestructura de servidores siempre es algo muy, muy, pero que muy, arriesgado.

Pero hay otra cosa a tener en cuenta: quien elija mantenerse con veriones antiguas de Windows, o de cualquier otro software, con vulnerabilidades si solucionar, será responsables de su decisión. Jurídicamente responsable. Ante un problema serio podría ser llevado a juicio en un proceso en el que se pronunciarían palabras y expresiones como "negligencia" o "falta de celo".

Si se disponía de alguna certificación de seguridad, a la próxima auditoría posiblemente se deje de tenerla. Y también habría que temer del resultado de las auditorías si se tienen ficheros con datos de carácter personal.

Vaya, vaya, vaya...
   

SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (5 de 6)

QUÉ HARÁN

********************
Índice
Parte 1
Parte 2
Parte 3
Parte 4
Parte 5
Parte 6
********************

Pongámonos en el papel de un ciberdelincuente. Por ejemplo, de alguien que se gana la vida infectando ordenadores con virus para después controlarlos o acceder a sus contenidos. ¿Qué actitud mantendríamos al respecto?

Por ejemplo, si hoy consiguiéramos descubrir una nueva vulnerabilidad en Windows XP... ¿qué haríamos?

Si la utilizamos hoy, posiblemente alguien se dé cuenta. Quizá alguna casa de antivirus detecte nuestras actividades y termine sabiendo de la vulnerabilidad y publicándola. Poco después, Microsoft la corregiría y con ello habría terminado con, o al menos limitado mucho, nuestras posibilidades de utilizarla.

Pero si nos esperamos y nos la guardamos unos meses, hasta que Microsoft deje de dar soporte para Windows XP, ya no habrá actualizaciones que la solucionen. Nos durará para siempre.

Además, tendríamos que pensar en la competencia. Si estamos en un negocio tenemos que pensar en hacernos con una buena cuenta de mercado y evitar que los demás nos la quiten. Nos convendría que nuestros ataques pasaran desapercibidos el mayor tiempo posible. No hacer demasiado ruido y conseguir que nuestro malware no sea detectado. Sobre todo al principio, cuando una infección masiva podría forzar a Microsoft a publicar una actualización de seguridad fuera de "ciclo de vida".

No querríamos tampoco que la competencia supiera de la vulnerabilidad que hemos descubierto. Pero tendríamos que tener en cuenta que, si fuimos capaces de dar con ella, posiblemente alguien más también la encuentre. Si queremos tener control exclusivo sobre el tema, quizá tomaríamos medidas al respecto. Por ejemplo, creando nuestros propios parches, que aseguraran que la vulnerabilidad sólo pueda ser explotada por nosotros, e instalándolos en los equipos que consiguiéramos infectar.

Acabada la cuenta atrás, empezaría la carrera por infectar los equipos vulnerables antes que la competencia.

(continuará...)

SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (4 de 6)

AVIADOS VAMOS

********************
Índice
Parte 1
Parte 2
Parte 3
Parte 4
Parte 5
Parte 6
********************

Quien tenga Windows XP, ya sea una persona particular o una organización, se le plantean pues varias opciones:
* Migrar a otros sistemas operativos distintos de Windows.
* Migrar a versiones más recientes de Windows.
* Quedarse con Windows XP y pagar el "Custom Support".
* Quedarse con Windows XP y no pagar el "Custom Support", quedándose sin actualizaciones.

Visto lo visto, posiblemente habrá, como aún hay, mucha gente que siga utilizando XP durante algún tiempo. Y lo del "Custom Support" posiblemente no sea la opción más adoptada. Tiene un coste demasiado alto y, por otro lado, como ya se vio, tampoco supone una garantía de protección

Lo que nos plantea un escenario con un elevado número de equipos que no recibirán actualizaciones de seguridad. Equipos conectados a Internet. Equipos en los hogares. Equipos en las redes corporativas de las organizaciones.

El problema es que la ausencia de actualizaciones de seguridad no va a venir acompañada de la ausencia de nuevas vulnerabilidades. Cada nueva vulnerabilidad que se descubra seguirá presente en estos sistemas para siempre (al menos, mientras sigan teniendo Windows XP). No habrá un segundo martes del mes en que un boletín de seguridad la corrija.

Más bien todo lo contrario. Con la publicación de un parche de seguridad, Microsoft anuncia la existencia de un problema de seguridad y proporciona su solución... para el software que sí tienen soporte. Pero Windows XP, que no lo tiene, está basado en la misma arquitectura que sus hermanos más jóvenes como Vista, 7 y 8. Eso quiere decir que habrá vulnerabilidades en las versiones más recientes de Windows que también podrían afectar a XP.

Cuando Microsoft publique un parche de seguridad, digamos para Windows 8, los "malos" (y puede que también algunos "buenos") podrán analizarlo, hacerle una ingeniería inversa, y determinar cuál es la vulnerabilidad y ver si también afecta a Windows XP.

Y si es así, puede que sea, como los diamantes, "para siempre".

Vulnerabilidades que se conocen y que no son corregidas... Buena cosa para quienes tienen interés en tus datos, en tus comunicaciones, en invadir tu privacidad. Pon en la lista en primer lugar a los ciberdelincuentes. Y añade a los gobiernos y sus agencias. Y también a muchas organizaciones privadas que tienen interés en datos de particulares y otras organizaciones para mejorar su posición estratégica.

Y también estarán en este meollo los buenos profesionales de la seguridad, que necesitarán conocer las vulnerabilidades para realizar bien su trabajo y para tratar de solucionar los problemas lo mejor posible.

Cuando termine la cuenta atrás y llegue el 8 de abril de 2.014, toda esta gente comenzará una carrera. A ver quién llega primero.

Y dónde llega.

(continuará...)

SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (3 de 6)

QUE SI MIGRAR, QUE SI NO

********************
Índice
 Parte 1
 Parte 2
 Parte 3
 Parte 4
 Parte 5
 Parte 6
********************

Ya nos hacemos una idea de lo que nos dice Microsoft sobre el fin del soporte de Windows XP. ¿Y cómo afecta esto al usuario?

La propuesta de Microsoft es que deje de usar Windows XP y migre a versiones más recientes de su sistema operativo.

Pero eso no es tan fácil. Porque hay mucha gente que tiene sus propios motivos para seguir usando si viejo XP. Para empezar, los cambios de interfaz suelen echar para atrás. Se me viene a la cabeza las palabras de un amigo que, en 2.001, se me quejaba de que "ahora que estamos acostumbrados a como funcionan las cosas en Windows 98, nos cambian la apariencia de todo en XP". Ahora volvemos a cambiar...

Y eso de modificar lo que uno ya tiene no suele gustar demasiado ni siquiera al personal técnico informático. La máxima de "si funciona, no lo toques", por más prudente que pueda ser, a veces no combina bien con las necesidades de cambio.

Además, cambiar supone un coste. Para empezar, en formación y en la pérdida de productividad que pudiera producirse mientras se consiguen dominar y aprovechar las novedades. Pero también en adquisiciones de licencias de software.

Las versiones más recientes de Windows requieren ordenadores más potentes que los exigidos por XP. Así, para éste último se indica en http://support.microsoft.com/kb/314865/es que necesita
* Procesador Pentium a 233 megahercios (MHz) o mayor velocidad (se recomienda 300 MHz)
* Al menos 64 megabytes (MB) de RAM (se recomienda 128 MB)
* Un mínimo de 1,5 gigabytes (GB) de espacio disponible en el disco duro

... mientras que Windows 7 y 8 elevan sus necesidades a (http://windows.microsoft.com/es-es/windows7/products/system-requirements y http://windows.microsoft.com/es-es/windows-8/system-requirements):
* Procesador: 1 gigahercio (GHz) o más
* RAM: 1 gigabyte (GB) (32 bits) o 2 GB (64 bits)
* Espacio en disco duro: 16 GB (32 bits) o 20 GB (64 bits)

De modo que si alguien tiene su viejo equipo con Windows XP, quizá tenga que adquirir uno nuevo para poder utilizar Windows 7 u 8. Al final, sumando costes, habrá muchas personas y organizaciones que decidan no realizar el cambio. Los tiempos de crisis no suelen alentar este tipo de aventuras.

Y dile a los, casi siempre pocos, informáticos que dejen todo lo que están haciendo y cambien todos los PC de usuario. Eso sí, mientras siguen manteniéndolo todo funcionando y asegurándose de que nadie pierde ningún dato. A ver qué te dicen.

Posiblemente en muchos casos se decidirá esperar a que el ordenador se rompa y esperar a que el próximo que se compre venga con su versión de Windows.

Pero es que ni siquiera quien quiera migrar y tenga dinero y recursos para ello podrá hacerlo sin plantearse antes algunos posibles inconvenientes. Puede que algunas de las aplicaciones críticas para una organización requieran el uso de Windows XP en los clientes, quizá porque se basen en Internet Explorer 6, quizá porque las nuevas medidas de seguridad que se introducen en las versiones posteriores hacen que no funcionen, quizá...

Hasta ahora, la solución consiste en utilizar lo que se llama "Windows XP Mode", básicamente una máquina virtual de Virtual PC con Windows XP cuya interfaz se integra en la de su host. Pero que sea virtual no significa que no sea una máquina y, como se indica en http://windows.microsoft.com/es-es/windows7/install-and-use-windows-xp-mode-in-windows-7 , Windows XP Mode tiene el mismo ciclo de vida que Windows XP. O sea que se queda sin soporte...

(continuará...)

SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (1 de 6)

LA CUENTA ATRÁS

********************
Índice
 Parte 1
 Parte 2
 Parte 3
 Parte 4
 Parte 5
 Parte 6
********************

Cuando escribo esto es 6 de septiembre de 2.013, a las 16:00 horas.

Empiezo a contar los segundos. 18432000, 18431999, 18431998, 18431997, 18431996, 18431995...

Cuando la cuenta atrás llegue a cero habrá llegado el 8 de abril de 2.014. El fatídico día en que, 12 años y pico (393.292.800 segundos) después de su lanzamiento en octubre de 2.001, Windows XP finalice su actual fase de soporte extendido.

A los efectos de lo que nos preocupa en este blog, eso de que estemos en soporte extendido viene a significar que sólo se proporcionan actualizaciones de seguridad.

Y que, después de que acabe, no tendremos ni eso. Bien nos lo explican en http://www.microsoft.com/es-es/windows/endofsupport.aspx :

------------------
¿Qué supone el fin del soporte para los clientes?

Significa que tienen que decidir. Después del 8 de abril de 2014 ya no habrá más actualizaciones de seguridad, ni parches para errores no ligados a la seguridad, ni opciones de soporte -gratuitas ni de pago tampoco- ni actualizaciones de contenido técnico en la Web. Nota: los contenidos actuales en la Web estarán disponibles durante la fase de Soporte Online en modo Autoservicio.
------------------

O sea, que la información, las descargas, etc. que hay seguirán estando ahí por un tiempo. Pero, de cosas nuevas, nada se podrá esperar. Incluso, seguún se indica para casi todo en la información que proporciona Microsoft (http://support.microsoft.com/lifecycle/?ln=es), "Puede ser necesaria la inscripción en un programa de soporte para recibir estos beneficios para ciertos productos".

Pocas opciones dejan a quien quiera mantener operativos sus sistemas Windows XP.

Aunque alguna puede haber para alguna gente. En DiarioTI (http://diarioti.com/microsoft-cobrara-por-las-actualizaciones-de-windows-xp-despues-de-abril-de-2014/68041) se habla de la posibilidad de contratar con Microsoft lo que ellos llaman "Custom Supoort", un plan de soporte de pago con un coste estimado de unos 200 dólares anuales por PC.

Y ¿qué se puede esperar a cambio de esta importante suma de dinero? Nos lo explican en http://download.microsoft.com/download/3/a/5/3a5b342b-2f1b-4ebe-9261-98205902a74f/custom_support_agreement.pdf :

------------------
Legacy products or out-of-support service packs covered under Custom Support will
continue to receive security hotfixes for vulnerabilities labeled as “Critical” by the MSRC.
Customers with Custom Support that need security patches defined as “Important” by
MSRC can purchase these for an additional fee.
------------------

Que mal traducido al español queda:
------------------
Los productos obsoletos o service packs fuera de soporte cubiertos por Custom Support continuarán recibiendo hotfixes de seguridad para las vulnerabilidades etiquetadas como "Críticas" por el MSRC (el centro de respuesta de Microsoft). Los clientes con Custom Support que necesiten parches de seguridad etiquetados como "Importante" por el MSRC puede comprarlos pagando una cantidad de dinero adicional.
------------------

Nada se dice de las vulnerabilidades a las que se asigne un nivel de criticidad inferior a "Importante".

Como aquí nos estamos jugando algo, no está de más saber qué significa "Crítica" e "Importante".
(continuará...)

SE VA ACABANDO EL SOPORTE PARA WINDOWS XP (2 de 6)

LA CRITICIDAD DE LO IMPORTANTE

********************
Índice
 Parte 1
 Parte 2
 Parte 3
 Parte 4
 Parte 5
 Parte 6
********************


Nos quedamos en el post anterior preguntándonos sobre qué significa "Crítica" e "Importante". Otro documento de Microsoft nos lo aclara (http://technet.microsoft.com/es-es/security/bulletin/rating):
------------------
* Crítica: Vulnerabilidad que puede permitir la propagación de un gusano de Internet sin la acción del usuario.
* Importante: Vulnerabilidad que puede poner en peligro la confidencialidad, integridad o disponibilidad de los datos de los usuarios, o bien, la integridad o disponibilidad de los recursos de procesamiento.
* Moderada: El abuso podría reducirse en gran medida mediante factores como una configuración predeterminada, auditoría o dificultad de abuso.
* Baja: Vulnerabilidad muy difícil de aprovechar o cuyo impacto es mínimo.
------------------

Y aquí me planteo dos problemas.

El primero es que estas caracterizaciones las hace el MSRC. En este centro hay muy buenos profesionales pero, aún así, sus decisiones parten desde una perspectiva particular, propia. Y cada organización, a veces cada persona, es un mundo. Pensemos por ejemplo en una que permita una "denegación de servicio" de sus servidores web. Esa vulnerabilidad puede ser crítica, muy crítica, para una organización que base su modelo de negocio en la venta a través de Internet. Pero para una empresa que sólo utilice su presencia en la Red de Redes para hacerse publicidad el impacto sería, quizá, sólo moderado.

Y el segundo es que las vulnerabilidades no viven solas. Un mismo equipo puede tener(y de hecho casi seguro que tiene) un buen número de vulnerabilidades, muchas de ellas aún por detectar. ¿Qué puede ocurrir si se combinan dos o más en un ataque?

Veamos un ejemplo.

El boletín de seguridad MS13-053 (http://technet.microsoft.com/es-es/security/bulletin/ms13-053) describe una vulnerabilidad CRITICA de los controladores en modo kernel de Windows em los siguientes términos:
------------------
La vulnerabilidad más grave podría permitir la ejecución remota de código si un usuario consulta contenido compartido que inserta archivos de fuente TrueType. Un atacante que aprovechara esta vulnerabilidad podría lograr el control completo de un sistema afectado.
------------------

O sea, que alguien pueda ejecutar código en tu máquina y controlarla completamente de forma remota es crítico. En eso podemos estar de acuerdo.

Y vayan a continuación un par de ejemplos de vulnerabilidades que sólo son IMPORTANTES.

La primera está explicada en MS12-048 (http://technet.microsoft.com/es-es/security/bulletin/ms12-048):
------------------
La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo o un directorio con un nombre especialmente diseñado. Un atacante que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario actual.
------------------

Esta vulnerabilidad nos da una medida. El atacante puede ejecutar código, igual que antes, pero en este caso sólo conseguirá tener los permisos del usuario al que consiga comprometer. Eso es menos grave que si se consigue un control total del sistema, como en el caso anterior,... excepto si el usuario tiene permisos y privilegios que le otorgan un control total del sistema, claro.

Pero además, es que existen las vulnerabilidades de "escalada de privilegios". Como la descrita en MS13-063 (http://technet.microsoft.com/es-es/security/bulletin/ms13-063), que también está etiquetada como "IMPORTANTE".

O sea, que si un equipo tiene estas dos vulnerabilidades "importantes", quizá un atacante se las ingenie para aprovechar la primera para ejecutar código y la otra para conseguir elevar sus privilegios y ejecutar código con una cuenta más "poderosa". Una con permisos y privilegios que le otorguen un control total, o casi total, sobre la máquina.

Resumiendo: dos vulnerabilidades "importantes" combinadas pueden llegar a tener el mismo impacto que una "crítica". Y combinar vulnerabilidades es algo común en estos negocios...
(continuará...)

El router de mi amigo (4 de 4)

La infraestructura

¡Hora de probar!

Me hice con un espacio web en cierto “hosting gratuito” que en adelante, y a efectos meramente didácticos, llamaré “malicioso.example.com”. Y en él creé tres ficheros

Fichero 1: El Javascript

El primero de los ficheros se llamaba “a”. Nombre corto, pero suficiente. Al igual que el código que contenía:

Ése era el script que quería ejecutar aprovechando la vulnerabilidad XSS. En pocas palabras, carga la página de cambio de contraseña y busca la línea que contiene “var pwdUser”, que es donde aparece el valor de la contraseña. Una vez la encuentra, la manda al servidor malicioso.example.com, al puerto 9999, donde un proceso está a la espera de recibir noticias.

Fichero 2: El formulario fantasma

Ahora necesitaba que la víctima sufriera las consecuencias del ataque XSS. Para ello me aproveché la vulnerabilidad CSRF, creando una página que simulara el formulario de configuración de impresora del router, pero sin tantas comprobaciones tontas.

Y, de camino, metiendo en el campo de la marca y el modelo el código que disparaba el XSS.

Una vez dispuesto el formulario, un poquito de JavaScript adicional se encargaría de enviarlo sin necesidad de intervención del usuario.

Eso es lo que tiene el fichero 1.html:

Fichero 3: La página del engaño

Para acabar, la única página que el usuario tiene que ver. Con la promesa de sacar algo útil del router, se pide al usuario que inicie sesión en dicho dispositivo y a continuación pulse un botón. Su nombre, 0.html. Y su contenido:

Y al pulsar el botón se carga, de forma invisible, el formulario fantasma.

… Y éste aprovecha el CSRF para activar el XSS

… … Y el XSS extrae la contraseña y la envía al sitio malicioso

¿Funcionará?

Fichero 4: A la caza del incauto

Para saberlo, nada mejor que probarlo. El usuario recibe la noticia de que hay un sitio web muy chulo que tiene que visitar. Quizá un correo. Quizá buscando en Internet. Quizá...

Siguiendo las instrucciones, la víctima abre otra pestaña, inicia sesión en el router y vuelve a la página engañosa.

Sin que él lo sepa, en el sitio web malicioso.example.com hay un proceso esperando que alguien se le conecte al puerto 9999. Para estas pruebas, basta con un pequeño shell script que extraiga el valor de la contraseña y la muestre en pantalla.

Cuando el usuario haga clic en el botón, algo le aparecerá en la pantalla al atacante: la contraseña de su víctima

Y, sí, esta imagen también la retoqué para que no apareciera la contraseña de mi amigo.

Conclusiones

Moraleja: Aunque no me gano la vida con estas cosas, debo decir que en alguna ocasión que otra me consiguen algo de comer. Y una buena cena siempre sabe mejor cuando te la paga otro.

Bueno, eso y que si tienes un router de éstos, yo no terminaría de estar tranquilo del todo. Sólo iniciaría sesión en él en un navegador sin plugins (porque los plugins pueden acceder al contenido de las páginas y hacer peticiones en tu nombre) y en el que no tuviera abierta ninguna otra pestaña (por si acaso alguna hace cosas como las vistas anteriormente). Y una vez terminada la configuración, cerraría sesión y navegador antes de ponerme a navegar por otros sitios. Y, aún así...

Y si tienes otro router... échale un vistazo. La experiencia me dice que cada uno debería dedicarse a lo que mejor sabe hacer. Y muchos fabricantes de hardware, cuando desarrollan software... bueno... eso.

El router de mi amigo (3 de 4)

Una idea de esas que nunca son buenas

Seguí mirando. Ya tenía un nuevo XSS y no debía olvidarme del CSRF de la vez anterior. De hecho, es más que posible que existan más problemas similares, pues es de esperar que todas las partes de la aplicación tengan un diseño parecido. ¡Apañados vamos!

Había una página que permitía cambiar la contraseña de acceso al router. Lo habitual: pedía una vez la contraseña anterior y dos veces la nueva

Es bueno eso de pedir la contraseña antigua cuando quieres poner una nueva, porque así proteges al usuario, no sea que se despiste y alguien le pille la sesión abierta y se le ocurra alguna travesura. Y también pones más difícil la explotación de algunos Cross Site Request Forgery.

Bueno, claro, eso siempre y cuando no pongas la contraseña antigua en la propia página. Y este router la ponía en el código fuente:

¡No estarías esperando que pusiera la contraseña de mi amigo, verdad! Esta foto la tuve que retocar un poco para no fastidiarle más de la cuenta.

Cuando menos, llamativo sí que es. La versión router del usuario que pega un postit en la pantalla con su contraseña. Y, me pregunté... ¿para qué querrá alguien poner eso ahí? Unas líneas que había un poco más adelante proporcionaban la respuesta:

¡Para hacer esa comprobación! Una vez más, la seguridad puesta en entredicho para realizar comprobaciones del lado del cliente.

Sea como sea, eso de poner una contraseña de acceso dentro del código JavaScript de una página, en texto claro como el agua, no es algo que yo suela recomendar a nadie.

La idea general

Con eso ya tenía bastante para dar el golpe de efecto que me hacía falta para ganarme un ágape por cuenta ajena. El guión, visto desde el punto de vista del atacante sería:

- Creo una página en un servidor gratuito que, aprovechando la vulnerabilidad CSRF, haga que el router registre una marca y modelo de impresora que me permita insertar código JavaScript en la página.

- Ahora, tengo que asegurarme de la víctima ha iniciado sesión en su router.

- Engaño a mi amigo para que visite a continuación mi página maliciosa (la anterior, la del CSRF y todo eso).

- Con eso, consigo que el código JavaScript que escribí se ejecute.

- Dicho código Javascript carga la página de cambio de contraseña. Analiza entonces su contenido y extrae de él la contraseña actual y me la envía a mi servidor.

Y... ¡voila! Ya tengo la contraseña del router de mi víctima.

Otros objetivos

Elegí la contraseña por lo llamativo de obtener algo que debería ser secreto pero... podría haber elegido cualquier otra cosa. La “graciosa” combinación de Cross Site Scripting y Cross Site Request Forgery me permitía obtener cualquier cosa de cualquiera de las páginas que ofrecía el router.

Y, mirando a ver qué tenían, me encontré con cosas llamativas. Cosas como:

- Dirección IP interna y externa (cara a Internet) del router

- Configuración de la WIFI

- Equipos conectados al router, con su IP y su MAC

- Marca, modelo, revisiones del firmware y otros detalles del hardware

Podría haber escogido cualquiera de ellas… o todas juntas. Y, la verdad, si alguien pudiera obtener todos estos datos de un montón de routers tendria acceso a una de las mayores redes Wifi que conozco. A partir de la dirección IP externa podría determinar aproximadamente la posición geográfica de los routers. Si éstos tienen una lista blanca de MAC que pueden conectarse, tendría algunas válidas y podría configurarlas en sus tarjetas de red. El SSID, la passfrase y todo lo demás también lo sabría...

Ideal para quien quiere conectarse a Internet sin estar demasiado controlado.

Pero había mucho más:

¡En una de ellas aparecía el número de teléfono de mi amigo!

Porque resulta que el router “controla” también su teléfono.

Supongo que la pondrán ahí por si se le olvida al dueño. Igual que la contraseña.

Y podía conseguir eso sin modificar nada en el router. Porque modificando su configuración se podría apoderar uno de la red a la que da servicio.

El router de mi amigo (2 de 4)

Comprobaciones en el cliente 

Necesitaba saber si esa comprobación se hacía sólo en la parte cliente, en el navegador, o si el router también lo miraba. De ser sólo en el cliente sería fácil saltarse la restricción. Por ejemplo, en Firefox se podría utilizar las herramientas para desarrollador web del navegador para localizar el punto en que se fija la longitud máxima...

… y cambiar el 16 por 1600...

Y con eso me podría poner a escribir a gusto. Probé entonces a poner como marca y modelo:

";alert("XSS");aaa="

… pero, a pesar de todo mi trabajo, no me hizo caso.

La página comprobaba si en la marca y el modelo había caracteres “raros”. Pero... ¿qué pasaría si yo realizaba la petición directamente al servidor y evitaba el código JavaScript de la página?

Para probar, utilicé un proxy que permite interceptar y modificar las peticiones que realiza el navegador. El que tenía más a mano era WebScarab. Un poco anticuado, sí, pero aún válido para muchas cosas. Lo inicié, indicándole que quería interceptar todas las peticiones, y configuré el navegador para que lo usara.

Después, rellené el formulario de configuración de impresora con valores válidos e hice clic en aceptar. Webscarab me presentó la petición y se puso a mis órdenes:

Yo, confiado, sustituí el valor de ippMake

… y le dije a Webscarab que siguiera adelante con la petición. La respuesta del router traía regalo:

¡Un XSS que permite inyectar directamente dentro del código JavaScript! Eso no se lo encuentra uno todos los días.

MORALEJA: Está muy bien eso de restringir la longitud de los campos de texto y los caracteres que pueden contener, porque así puedes poner difícil las cosas a quien quiera hacer un uso indebido del sistema. Pero si sólo lo haces en la parte cliente, si no realizas también esas comprobaciones en la parte del servidor, estos controles pueden ser fácilmente evitados.

Además, había otra cosita que no me entretuve en estudiar. Parece que el programa del router no comprueba adecuadamente los límites, los tamaños, de las variables, porque una prueba que hice fue poner una cadena un poco más larga de la cuenta como marca/modelo:

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

… y por la respuesta del router, parecía que me había metido en el principio de otra cadena, puesto que me mostraba el final de ésta (“/dev/printer0”) concatenada con lo que yo había puesto.

Un overflow que, bien aprovechado, quizá diera mucho juego. Pero eso es otra historia...

El router de mi amigo (1 de 4)

La apuesta

Hace ya tiempo que os conté como ayudé a un amigo que tenía problemas con el botón de activar y desactivar la WIFI en su router. El único problema fue que el apaño lo hice aprovechando una vulnerabilidad CSRF que le encontré al equipo.

Por si alguien no lo recuerda... http://418iamateapot.blogspot.com.es/2013/01/el-csrf-del-router.html

Pues bien, hoy tuve tiempo y oportunidad de volver a ver a mi amigo. Todo iba bien hasta que me encaró y me dijo:

- ¿Sabes? Leí aquello que escribiste sobre el CSRF del router y todo eso. Y creo que hablas de “MI” router.

Parecía molesto. Yo, que no me lo esperaba, me las arreglé para poner cara de póker. Pero mi amigo se fue envalentonando:

- ¿Sabes? Creo que lo que cuentas no es verdad. Y si lo es, que no es del todo cierto. Y, aún así, que exageras. ¿Cómo va nadie a hacerse con el control de mi router desde Internet por visitar una página? Es que te gusta hablar por hablar...

Como, a estas alturas, uno ya empieza a ver claras algunas oportunidades, le miré a los ojos y le espeté:

- A que no eres capaz de apostarte una cena.

Eso fue todo lo que hizo falta para herir su orgullo y hacerle caer. Mientras él decía “¡apostada queda!”, yo llamaba por teléfono a casa y decía:

- Iros arreglando, que hoy comemos fuera.

Un XSS... y algo más

Entré al router con el usuario y la contraseña que ya conocía de la vez anterior y me puse a navegar por menús y opciones. Una cosa chula que tenía el cacharro era que podía compartir una impresora entre los equipos de la casa. El formulario para configurar esta opción era bastante sencillo

Cuando analicé el código fuente de la página, comprobé que había un código Javascript que rellenaba los campos con los valores almacenados en el equipo.

Y pensé: ¡No va a ser tan fácil!


Pero sí lo era. El router debe tener una instrucción que genera

var ippMake = "

… y a continuación pone el valor que corresponda a la marca y modelo de la impresora. Finalmente, cierra la cadena y la instrucción al añadir:

";

¿Qué pasaría si pongo una marca y modelo que contenga una comilla doble? Por ejemplo

marca"modelo

Pues... que el programita del router lo copia todo sin hacer más comprobaciones y terminaríamos teniendo un código JavaScript con errores de sintaxis por una cadena mal cerrada.

var ippMake = "marca"modelo";

Pero, oye, eso nos puede permitir insertar instrucciones nuevas dentro del código JavaScript. Si nuestra impresora fuera de una marca rara, digamos:

";alert("XSS");aaa="

Terminaríamos teniendo:

var ippMake = "";alert("XSS");aaa="";

Y eso nos permitiría ejecutar “cosas nuevas” en las páginas del router.

Claro que algún problemilla habría que superar. Y es que el campo en el que se pone la marca y el modelo sólo permite insertar un máximo de 16 caracteres. Pocos para lo que yo necesitaba.

Experimentos en DataLand (1)

EL ENTORNO

NOTA: No es mi intención sacar aquí ningún tipo de conclusiones. Simplemente, hice algunas pruebas y los resultados me parecieron interesantes. Repetí varias veces las pruebas, por si acaso, pero no sé si a ti te funcionarán igual. Si decides hacer comprobaciones, me gustaría que compartieras cómo quedó la cosa.

La última vez quizá dejé a alguien con la miel en los labios. Empecé a hablar de Seguridad y, acto seguido, concluí el post. Retomemos el tema.

Como dije, me puse a hacer pruebas con eso de las URI de tipo "data". Si llegaste hasta aquí saltando de enlace en enlace y no sabes qué eso de una "URI de tipo data", te adelanto que es una forma de incrustar dentro de un documento HTML una cosa tal como una imagen o un documento. De guardarla DENTRO del propio documento HTML, no en otro fichero aparte. Repito una vez más las referencias que doy siempre:

http://en.wikipedia.org/wiki/Data_URI_scheme y, barriendo para casa: http://418iamateapot.blogspot.com.es/2012/12/dos-xss-mas-cerradas-en-roundcube.html y  http://www.elladodelmal.com/2012/12/roundcube-ii-nuevos-vectores-para.html

 Para las pruebas utilicé un viejo (¡quién lo habría dicho en su momento!) pero aún solvente equipo con CPU Core(TM)2Duo T9300 y 4 GB de RAM, Windows Vista Business Service Pack 2 y Microsoft Security Essentials actualizado. En él tengo instalado VirtualBox y un BackTrack virtualizado que se come 512 MB de RAM y con el que suelo hacerle puñeterías a otras máquinas virtuales.

Y hoy, quizá, también  a la máquina real.

En el BackTrack, cuya IP de hoy es 192.168.27.100, tengo un fichero “con premio”. Un PDF malicioso que, como pude comprobar, es detectado por el antivirus.

ENDATANDO EL FICHERO

Para jugar con él, creé un fichero HTML que le referenciara. Le puse de nombre “capa1.htm” y su contenido quedó así:

<object height="100%" width="100%" data="malicioso.pdf" type="application/pdf"

Entonces, realicé la conversión mediante un comando como

$ ruby poc.rb /var/www/capa1.htm /var/www/prueba1.htm

El resultado, “prueba1.htm”, contiene dentro los datos del PDF codificados en una URI de tipo data:

Pero no me conformé con convertir una sola vez a “data”. Así que creé otro fichero, “capa2.html” con un iframe para contener a “capa1.htm”:

<iframe src="capa1.htm" width="100%" height="100%"></iframe>

Y lo convertí también con:

$ ruby poc.rb /var/www/capa2.htm /var/www/prueba2.htm

El programa “poc.rb” realiza la conversión de forma recursiva, de modo que ahora tenemos el documento PDF pasado a "data" e incrustado en un objeto y todo eso lo vuelto a convertir a "data".

Pero con dos iteraciones tampoco me pareció suficiente e hice otro documento HTML que incrustara a “capa2.htm” y lo llamé “capa3.htm”:

<iframe src="capa1.htm" width="100%" height="100%"></iframe>

Y un “capa4.htm” que incluyera a “capa3.htm”... y así hasta “capa10.htm”, que incluye una referencia a "capa9.htm". Y a todos ellos los pasé por mi “prueba de concepto”. El último, "prueba10.htm" contiene el PDF pasado 10 veces por el procedimiento de conversión a "data". Suficiente por ahora.

¡A JUGAR!

Quería tener los diez ficheros obtenidos así como el documento PDF original en el PC. Así que desactivé momentáneamente la protección en tiempo real del antivirus...

… y me los descargué a una carpeta:

… para a continuación pasarle un análisis en busca de amenazas. "A ver qué me encuentra el Security Essentials":

… Y no tardó en cantar:

Pero cuando terminó y me preocupé por ver en qué ficheros había detectado los problemas...

… ¡sólo en dos de ellos! En el PDF original y en el HTML para el que sólo había realizado la conversión a data una única vez. A pesar de que le había dicho al antivirus que eliminara el "virus", seguía teniéndolo nueve veces en mi sistema.

CONCLUSIONES

Reactivé la protección en tiempo real, que aunque no sea suficiente para garantizar nada por sí sola  (diría un matemático que es "condición necesaria, pero no suficiente"), siempre algo ayuda y me quedé pensando...

En realidad, no tengo del todo claro hasta qué punto sería bueno o malo que un antivirus mirara los documentos codificados como "data" en busca de documentos codificados como "data", en busca de documentos codificados como "data", en busca de documentos codificados como "data", en busca de...

Si lo hiciera, quizá habría malware que, para evitar ser detectado, llenaría carpetas de ficheros con documentos codificados como "data" de forma iterativa cien o doscientas veces. Señuelos con que entretener un buen rato al antivirus mientras "uno hace su trabajo".

Pero, por otro lado, si yo fuera un %#”!~@@!!! de esos que hay por ahí, podría pensar en utilizar esto para muchas cosas. Aparte de ocultar una copia de mi malware, o de otros elementos maliciosos, de forma que no lo encuentren, claro.

Cosas como alojar contenidos no autorizados en los sistemas de almacenamiento corporativos o en servidores webs ajenos. O compartir en redes P2P cosas que no quiero que sean detectadas fácilmente por sistemas automáticos de control.

O, en un caso de robo y fuga de información confidencial, para tratar de enviar un archivo sin ser detectado, codificándolo varias veces a “data” y poniéndolo como destino de un hiperenlace en un correo redactado en formato HTML.

O... ¿Se te ocurre alguna cosa más? Alguna, seguro que sí.

Y... ¿Has probado tus sistemas de protección a ver si detectan cosas como éstas?

La próxima vez os cuento algunas pruebas más que hice.

El Ruby Mola

Hace tiempo que tengo descuidado este blog. Demasiado.

Pero ha sido por una buena razón. Todo empezó cuando me puse a hacer “limpieza de papeles”. De vez en cuando es bueno mirar qué tiene uno y tirar todos los papeles inútiles que ha ido uno acumulando. Tickets de haber comprado un refresco en el super, folletos de propaganda, documentos secretos que después vas buscando como loco cuando te vuelven a hacer falta...

Y en eso estaba yo cuando me encontré un viejo bloc de notas. Lo abrí y...¡allí estaban! Las notas que fui tomando cuando empecé a aprender a programar en Ruby. ¡Qué recuerdos!

Una cosa de la que me dí cuenta inmediatamente fue que muchas de aquellas cosas las había olvidado y vuelto a descubrir varias veces. Así que decidí crear una página web en Internet e ir poniendo en ella aquello que me parecía más relevante. De ese modo, tarde o temprano, terminaría copiando todo lo que había escrito en mi bloc y podría tirarlo tranquilamente.

Aunque la página web estuviera hecha especialmente para mí, si a alguien más puede valerle... mejor que mejor. Así que decidí darle un enfoque medio didáctico en el que se fueran completando pasos para llegar a un objetivo establecido desde el principio.

El objetivo consistía en crear un analizador de código HTML. Y poco a poco fue saliendo. Cuando estuvo listo, quise hacer algo que entroncara con este blog y me acordé de las URIs de tipo “data:” y cómo las utilicé en su día para realizar ataques de Cross Site Scripting contra webmails basados en RoundCube. De ese tema escribí por aquí y, con más detalle, en "Un informático en el lado del mal" .

Así que utilicé el analizador de HTML para crear un programa que convierte en URIs de tipo “data” las referencias externas de una página web: sus imágenes, sus scripts, sus hojas de estilo en cascada, sus objetos,...

En lo que se tarda en parpadear me pondré a escribir un post sobre cómo se puede aprovechar una herramienta de este tipo para evaluar la seguridad de un equipo y de algunos programas. Porque casi todas las herramientas sirven para más de una cosa. Y supongo que habrá a quien no haya que decirle mucho más para que se vaya haciendo una idea...

Mientras tanto, hago los honores y, aunque le queden cosas por pulir, presento mi blog de Ruby en sociedad. Creo que ya puede empezar a ser útil. Ahí va el enlace:
El Ruby Mola

… y el índice del proyecto de analizador de HTML.
Analizador HTML

Hay cosas que no puedes comprar

Una al día es una fuente indispensable de información para quienes, como es mi caso, se interesan por eso de la Seguridad de la Información. Porque encontrarse cada día con una noticia de interés no es moco de pavo.

Últimamente las noticias hablan mucho de Java. Posiblemente sea lo que toca este año. Y una de ellas cuenta una historia cuanto menos curiosa: Facebook, Twitter y Apple sufrieron fueron "atacados". Equipos de sus redes internas fueron infectados con malware. Y la culpa, dicen, parece ser... de Java.

¿Cómo? Bueno, se supone que estas compañías cuentan con sistemas de seguridad que impiden que nada "entre" en sus sistemas. ¿Verdad?

Sí, verdad. Pero si la montaña no viene... habrá que acercarse uno.

En primer lugar, los ciberdelincuentes conocían una vulnerabilidad de Java y crearon un código mailicioso que se aprovechaba de ella. Después buscaron páginas web a las que la gente de Facebook, Twitter y Apple se conectaban habitualmente y las analizaron para ver si alguna era vulnerable.

Finalmente, infectaron las páginas web vulnerables y les introdujeron el código malicioso que tenían preparado. Y cuando la gente las visitaba... se infectaba. El malware no entraba desde fuera. Eran los propios usuarios quienes, al visitar las webs vulneradas y sin saberlo, "salían a recogerlo".

Se combinan así dos tendencias en esto de la seguridad: el ataque a los puestos clientes y el "envenenamiento de pozos".

Con todo, lo que más me llamó la atención de la noticia fue una frase que decía: "Facebook se apresura a admitir que sus sistemas estaban completamente actualizados y que contaban con un antivirus". Porque mientras nos quedemos ahí, la batalla estará perdida.

Hay una frase que se repite mucho: "La Seguridad no es un producto; es un proceso". No puedes comprar la seguridad. No se puede conseguir a base de instalar o poner en marcha herramientas. No puedes pagar a nadie para que te la proporcione. La verdadera base de la Seguridad consiste en determinar tus objetivos, establecer qué actuaciones debes llevar a cabo, realizarlas, evaluar los resultados obtenidos,... y volver a empezar.

Seguridad tiene más que ver con Altos Mandos, Jefazos, que se implican y establecen políticas acertadas, las ponen en marcha. Con que todo el mundo sabe lo que tiene que hacer y lo hace. Con que los resultados se miden...

Mucho más que con un hacker que explota una vulnerabilidad.

Y por eso, en estos tiempos en los que todo el mundo piensa en soluciones basadas en la nube y en externalizar, puedes comprar herramientas y ponerlas en funcionamiento. Puedes contratar a empresas, a partners que te ayuden en aquello que tú no dominas. Puedes subcontratar algunas actividades. Puedes hacer mil cosas.

Pero hay dos cosas que no puedes hacer. Una es pensar que eso de la Seguridad es sólo un problema informático. Y la otra, dejar en manos de terceros lo que realmente es importante: el enfoque estratégico y global. Creo que si alguien te intenta convencer de lo contrario, no te vende "la nube".

Te vende humo.

Seguridad subjetiva

Hoy no tenía pensado poner nada nuevo en este blog. De hecho, llevo cosa de un mes sin hacerlo porque últimamente estoy dedicando mi poco tiempo libre a un "proyecto paralelo". Ya os daré noticias.

Pero he visto un par de noticias de aquellas que hacen pensar.

La primera es la polémica que se ha levantado en el Reino Unido por un juguete:
http://es.noticias.yahoo.com/set-playmobil-representa-atraco-banco-desata-polemica-104345591.html

Resumiendo: hay un paquete de los Clics de Playmobil para "jugar a los bancos" que, entre otras cosas, trae su atracador con pistola y todo.

Aunque nunca me gustaron los juegos de armas, por mi edad, me crié en una época en que jugábamos a policía y ladrones sin que eso supusiera un problema. Los Clics piratas, en su barco, atacaban al Castillo. Los Geyperman y Madelman realizaban acciones de comando...

Quizá aquello fuera demasiado. E inadecuado. Pero creo que estamos sobrepasando el punto a partir del que las medidas son contraproducentes.

Demasiada sobreprotección. Bruce Schneier en uno de sus artículos explicaba como la sobreprotección es mala para la seguridad. Y ponía como ejemplo los parques infantiles. En mi época, el suelo era de gravilla y si te caías te arañabas entero. Hoy son blanditos (al menos por donde yo vivo) y amortiguan los golpes. Como consecuencia, las generaciones más jóvenes, al no haberlo vivido, aprenden a desestimar el riesgo.

El riesgo ya es de por sí difícil de evaluar como para poder permitirnos el lujo de desconocerlo. Concluía Bruce Schneier señalando que esto haría que las personas jóvenes asumieran los riesgos con una naturalidad que puede terminar siendo peligrosa. 

Y, si nos fijamos en las atracciones de feria, algo de razón tiene. Cada vez se piden sensaciones más extremas.

Con todo, lo que más me llamó la atención de la noticia anterior fue un enlace que encontré en ella:
http://es.noticias.yahoo.com/blogs/gaceta-trotamundos/una-ni%C3%B1a-cinco-a%C3%B1os-expulsada-por-terrorista-su-144039104.html

Expulsan del colegio por terrorista a una niña de CINCO AÑOS que había invitado a sus compañeros a dispararse unos a otros con UNA PISTOLA DE POMPAS DE JABÓN DE HELLO KITTY.

¿Gracioso? No para la familia. La niña fue expulsada y ahora tiene una mancha en su historial que hace que ningún colegio quiera admitirla.

Estamos en una época en que, bajo la bandera de la protección antiterrorista se están tomando medidas que puede que parezcan destinadas a mejorar nuestra seguridad, pero que, en muchos casos, claramente no pasan de ser meros aparatos formales, simples maniobras de distracción que no aportan ni un grano de arena a la verdadera seguridad pero (como algo había que hacer) simulan hacerlo.

Porque parten de decisiones estratégicas mal tomadas. O de decisiones que, debiendo ser tomadas con carácter estratégico, se toman con el corto plazo en mente o, peor aún, a remolque de los hechos que se van produciendo.

Y es preocupante como puede afectar eso a nuestras libertades y derechos,

Cómo no se deben hacer las cosas (2): Jugando al escondite con un webmaster

Este es el segundo de una serie de posts. En el primero se mostró como una página había caído víctima de unos ciberdelincuentes que la habían utilizado para promocionar una web que decía vender programas.

Vale. ¿Y qué? Que una web sea modificada de forma autorizada no es nada nuevo. Ni siquiera los expertos en seguridad están libres de este riesgo. O incluso lo están menos que otros porque son un objetivo llamativo. No es de extrañar que gente tan reconocida en este mundillo como John Strand, de Paul Dot Com, pidan disculpas por adelantado, por si acaso y para cuando ocurra... lo que parece inevitable.

Ni tampoco son nuevas las técnicas de promoción de sitios web en buscadores utilizando técnicas ilegítimas o ilegales. Por darme autobombo, ya hace tiempo que mi amigo Chema Alonso y yo escribimos al respecto en Técnicas SEO para gente de moral relajada, o que hablé sobre el tema en una charla o que le dediqué un capítulo de un libro sobre buscadores. Y en su momento hice una herramienta para detectar precisamente este tipo de comportamientos y la íbamos a presentar en la Open Source World Conference de 2010 en Málaga.

Sí, esa que al final no llegó a celebrarse por falta de dinero.

Bueno, vamos a ir dejándonos de "anuncios". Entonces... ¿A qué repetirme otra vez aquí?

En esto, como en tantas otras situaciones, lo malo no es tanto que te la peguen como no darte cuenta. O no querer darte cuenta. O no hacer lo posible por darte cuenta. O... Sigamos con la historia...

En casos como éste, en que el problema es notorio y está registrado en Google, entiendo que lo más apropiado es tratar de contactar con el webmaster y contarle lo que uno ha visto. En casos como éste, digo, porque hay otros en los que lo más seguro para uno es callarse o comunicar la noticia a través de intermediarios. Que no se quieren para nada los problemas legales.

Así que me fui a la página de "contacta con nosotros":

Perfecto. Una dirección postal, por si quiero enviarles una carta, y una lista de distribución. ¿Acaso debería pegarle un sello a un sobre y esperarme a que llegue mi misiva? ¿o es preferible mandar la información a la lista y que todo bicho viviente que esté registrado en ella lo sepa?

Pues, esto último... ni aunque creyera yo que es lo correcto. Porque el enlace no furula:

Fallo número 1. Si tienes un sitio web, ten siempre una forma de contacto ágil para que te puedan contar estas cosas y no te conviertas así en el último en enterarte. Como aquel al que...

Para tener la conciencia tranquila, mandé el correo al webmaster de www.mit.edu. Algo tendrá que ver con este dominio, espero. Después pensé "seguro que en algún sitio hay otro dato de contacto" y navegué un poco por la web. Y me fui dando cuenta de lo poco actualizada que estaba

Desde finales del 2011 no había nada nuevo. Ummmmm....

Fallo número 2. Si no necesitas ya un sitio web, no lo mantengas operativo.

Cada cosa que pones aumenta tu superficie de exposición, haciéndote más vulnerable y complicándote la vida un poco más. Por no hablar de los costes que pudiera suponer.

Aunque, a lo mejor, sí que lo necesitan. Quizá sea un repositorio de documentación interesante. Como no veía nada por fuera que me fuera determinante, decidí echar un vistazo al código fuente y...

¡Jommla 1.5! ¡Pero si eso ya va por la versión 2.5.8 (recomendada por los de Joomla para uso general) y 3.0.2 (para los valientes)?

Fallo número 3. Si tienes un sitio porque lo necesitas, mantenlo actualizado.

Vamos a ver: no se trata de que las versiones más modernas no tengan vulnerabilidades. Donde radica la verdadera diferencia entre la úlima versión y las versiones antiguas es en que las vulnerabilidades de éstas últimas son muy, pero que muy, conocidas. Y hasta en las webs de numismática se las encuentra uno a veces explicadas.

Teníamos una página web que se comportaba de tres formas diferentes. De forma similar, los tres fallos que hemos encontrado se pueden resumir en uno: no pongas en marcha nada que no seas capaz de mantener en el futuro y gestiónalo de forma integral y responsable.

O, lo que es lo mismo, no caigas en la "trampa del elemento facilitador". No instales nada simplemente porque puedes hacerlo y es gratis. Primero porque, al final, nada es gratis. Y después porque si no estás en condiciones de poner encima de la mesa los medios económicos, organizativos, técnicos y de cualquier otro tipo... al final algo saldrá mal.

Y, cuando pase, mejor será que te enteres pronto y le pongas solución.

Resumiendo y utilizando las expresiones de otros: "no instales sistemas por encima de tus posibilidades".

A estas alturas, me hago una idea sobre cómo consiguieron hacerle la fechoría a la página. Quizá algún día tenga ocasión de contarlo.

Quizá. Así que... (continuará)

Cómo no se deben hacer las cosas (1): Barato lo llevo, oigaaa

Cuando uno se pone a mirar, a veces ve cosas llamativas. Algunas de ellas son tan típicas, tan... paradigmáticas, que creo que podrían servir de ejemplo para todo el mundo. Y hace unos días me encontré con una de ellas.

No sé cómo, pero me encontré intentando ver si el MIT (Massachusetts Institute of Technology) vendía software barato. Quizá parezca que soy raro, pero mis razones tenía. Así que fui a Google y puse:

 site:mit.edu "cheap autocad"

 Me salieron unos cuantos resultados. Así que, por probar, hice clic en el primero de ellos y...

 Como se puede ver en la imagen, no terminé en el MIT. En su lugar, fui redirigido a una página muuuuuuy rarita. ¿Que cómo? Pues, analizando la respuesta del servidor, me encontré con las siguientes cabeceras HTTP:

---

Status=Moved Temporarily - 302
Date=Tue, 29 Jan 2013 16:02:09 GMT
Server=Apache
P3P=CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Content-Encoding=gzip
Vary=Accept-Encoding
Location=http://uzsrodghwira.jet-software.net/browse/search/?q=autocad+architecture
Scripts-IP=18.181.0.46
Keep-Alive=timeout=15, max=1000
Connection=Keep-Alive
Transfer-Encoding=chunked
Content-Type=text/html

---

Bueno, una redirección HTTP 302, "Movido Temporalmente" a un sitio extraño. OK, ese servidor hacía cosas bastante extravagantes. Pero había más.

Por lo visto hasta ahora, a esa web del MIT le han calzado uno del 48. Alguien se les había colado y les había metido cosas feas. Pero supongamos que yo me doy cuenta y aviso al administrador del sitio. Supongamos que le envío un correo y le digo que la dirección http://ceer.mit.edu/?sc=7222 lleva a una tienda posiblemente ilegal de software.

Y supongamos que quien recibe mi mensaje prueba y pone en la barra de direcciones de su navegador la URL que le doy. Entonces, le aparacerá esto:

¡Ahora resulta que esa URL lleva a la página principal del sitio! El administrador posiblemente pensará "¡qué poca gracia tenía esta broma!" o "¡la gente ya no sabe ni lo que visita!" y se olvidará del tema.

En esta ocasión, las cabeceras HTTP de la respuesta indican que también ha existido redirección, pero no a otra web:

---

Status=Moved Temporarily - 302
Date=Tue, 29 Jan 2013 16:06:20 GMT
Server=Apache
P3P=CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Content-Encoding=gzip
Vary=Accept-Encoding
Set-Cookie=8519503dbe949327cf1a7a153cc6f9ec=d0d26ddbbc41fd742852af53c3852a28; path=/
Location=/
Scripts-IP=18.181.0.46
Keep-Alive=timeout=15, max=1000
Connection=Keep-Alive
Transfer-Encoding=chunked
Content-Type=text/html

---

Simpático ¿verdad? El tipo maluto tenía su truco. Su "regalo" mira las cabeceras HTTP de las peticiones y, en particular, la del "Referer". Cuando uno sigue un enlace, el sitio web de destino recibe en esta cabecera la URL del documento desde el que surgió la petición. Y el script malicioso, sabiendo esto, unicamente redirige al visitante a su "tienda" cuando aquel viene desde Google, o quizá también desde algunos otros buscadores.

Pero había más. Porque en la primera imagen se puede ver cómo percibe Google el documento de la URL que nos trae de cabeza. Y no se parece ni a la tienda ni a la página de inicio del sitio. Google ve otra cosa diferente. Quizá tenga que ver con la cabecera HTTP "User-Agent", que identifica al navegador con el que se realizan las peticiones. Muchas veces, así ocurre.

Google tiene un programilla llamado "GoogleBot" con el que va rastreando páginas web. Y tiene su propio "User-Agent". Podemos saber cuál es consultando la versión en cache de Google de algunas páginas de esas de "mira qué User-Agent tienes". Probando con una de ellas:

¡Ahí está! Ahora, cogiendo el Firefox con la extensión "Tamper Data" podemos volver a pedir nuestra página camaleónica y cambiar el valor del User-Agent para utilizar el de GoogleBot.

... Y ¡Bingo! La tercera versión de la página:

Así, que esta gente le da a cada uno lo que busca. En este caso, a Google, un galimatías de palabras pero que tienen varias veces eso de "cheap" y algunos nombres de programas

 ¡Con tal de hacer caja!

Por supuesto, quise notificar todo esto al webmaster del sitio. Pero...
(continuará)