Protege en tu CMS la ejecución de acciones preparadas para tu dios CHRONO #WordPress #Moodle #PrestaShop

En la mitología griega, Chrono es el dios que personificaba el tiempo, y de él han llegado hasta nuestro tiempo las connotaciones temporales en nuestra cultura para muchos de nuestros términos. En los sistemas UNIX, cron es el daemon que gestiona la ejecución de las acciones planificadas a lo largo del tiempo, siguiendo una partitura escrita en el fichero crontab. Configurar este fichero y los comandos de cron es la manera de sacar partido al planificador de tareas en sistemas UNIX y conseguir que recurrentemente se hagan determinadas acciones.

Figura 1: Protege en tu CMS la ejecución de acciones preparadas para tu dios CHRONO

En aplicaciones web, también es necesario realizar acciones planificadas de forma recurrente, centradas en lanzar tareas de mantenimiento, o para ejecutar funciones que tienen que suceder cada cierto tiempo. Muchos de los frameworks CMS de aplicaciones web (y los plugins de estos) que se utilizan habitualmente en muchos sitios de Internet necesitan esas funciones recurrentes planificadas, para lo que suelen crear un fichero que debe ser invocado cada cierto tiempo.

Figura 2: Arquitectura de ficheros cron en un CMS

La forma en la que se configura esto habitualmente es mediante la introducción de una entrada en el fichero crontab del sistema que invoca un fichero donde se encuentran los comandos con las acciones que el framework necesita hacer recurrentemente. Si los comandos están basados en el motor del sitio web, es decir, el engine PHP, JSP o .NET, la invocación del fichero se hace mediante una llamada a una URL que está publicada en la web.

Figura 3: Ejecución de tareas configuradas en el fichero cron.php de un framework

Cada vez que se realiza esa llamada a esa URL, la lista de tareas definidas dentro de ese script, que suele llamarse cron.php, cron.jsp o similares, es ejecutada a través del motor PHP, JSP o .NET que está soportando el sitio web. Y esto, si no se hace de forma segura, puede ser un problema para el sitio web.

Figura 4: Ejecución de recordatorios en el fichero cron.php de un plugin

Los ficheros cron.php realizan acciones en el sitio web que pueden ser de mantenimiento, consumiendo a veces altas cargas de tiempo de CPU, volúmenes de datos o memoria RAM. Esto podría ser aprovechado por un adversario para hacer un ataque de Denegación de Servicio al sitio, pero además puede conllevar consumos económicos si es un sitio que está en un entorno Cloud de pago por consumo.

Figura 5: Invocación de un fichero cron.php de una instalación de Moodle

En el artículo dedicado a Pentesting de Moodle en el blog de FWHIBBIT explicaban el otro día un caso concreto con el cron de este framework en muchas instalaciones, que además es bastante "verbose" y si no está protegido se puede ejecutar, en cada llamada, un consumo del sistema. En este caso, se puede ver al final del mismo la memoria que ha tomado la ejecución de estas acciones.

Figura 6: Resumen del consumo de la ejecución de las acciones de cron.php de un Moodle

Estos ficheros, dependiendo del framework que se use, pueden tener diferentes nombres y formatos. En el caso de los sitios con instalaciones de WordPress, es común encontrarse con WP-Cron.php que se usan para la búsqueda de actualizaciones, la realización de copias de seguridad, o la publicación programada de artículos. Se pueden buscar en cualquier sitio web basado en WordPress y ver si existen o no en el sitio, si están prohibidos o permitidos e, incluso, ver si están correctamente configurados o no.

Figura 7: WP-Cron.php de un WordPress con errores de configuración

Lo más curioso es que no solo los frameworks de aplicaciones web cuentan con estos ficheros cron.php para las acciones globales recurrentes o planificadas, sino que muchos plugins suelen tener sus propios ficheros de planificación de tareas que también se dan de alta en la configuración del daemon cron en el sistema. 

Figura 8: Fichero cron.php para un plugin de WordPress

En este ejemplo de la Figura 4, un plugin está enviando recordatorios cada vez que se invoca, y en el caso del plugin de BirthDayPresent, para el framework PrestaShop, se envía un e-mail cada vez que se ejecuta su cron.php a todas las personas que ese día cumplen años.

Figura 9: Fichero cron.php en plugin BirthdayPresent de PrestaShop

Por supuesto, si un atacante puede invocar estos ficheros, existe un riesgo para la seguridad del sitio, por lo que se buscan diferentes estrategias de seguridad. Desde proteger el fichero para que solo pueda ser invocado por un usuario, para que solo pueda ser invocado desde una determinada dirección IP o para que se pueda pedir su ejecución solo con un token de seguridad.

Figura 10: Distintas protecciones en ficheros cron de plugins y frameworks

Si esto no está protegido, entonces el sitio cuenta con un problema de seguridad que debe ser subsanado. Si tienes un CMS, con un framework, busca todos los ficheros con tareas para tu daemon cron y comprueba que todos ellos están protegidos contra una invocación no autorizada por parte de visitantes de tu web.

Saludos Malignos!

Hackear un Moodle con Network Packet Manipulation

El siguiente ejercicio trata de explicar cómo se puede hackear un servidor Moodle mediante la utilización de la técnica de ataque de Network Packet Manipulation, tal y como ya se ha visto con WordPress, con la que se pueden modificar las consultas a MySQL al vuelo cuando las conexiones a la base de datos no están cifradas. Es bastante común que la aplicación web y la base de datos que utiliza dicha aplicación web estén instaladas en la misma máquina, sí, pero en muchos caso - sobre todo en entornos corporativos - estas dos capas están separadas.

Figura 1: Hackear Moodle con ataques de Network Packet Manipulation

Lo primero que se debe hacer es analizar las consultas de Moodle y conocer un poco como gestiona éste su base de datos. En este caso el proverbio “ten cerca a tus amigos para cerca aún a tus enemigos” recobra un poco valor a la inversa, es decir, tenemos que estar lo mas cerca posible de nuestra víctima en el sentido de que debemos conocerla a la perfección para poder llevar a cabo el ataque de forma sencilla y con éxito. En el escenario para las pruebas de concepto están como sigue el esquema siguiente:

Figura 2: El servidor Moodle y la motor SGBDR de MySQL se conectan vía red

Para ello se ha estudiado qué tablas hay en la base de datos que utiliza una aplicación Moodle y cuáles nos podrían interesar. Como en este caso queremos hacernos con el control del Moodle, lo que necesitaremos es saber dónde se aloja la información de los usuarios registrados en el sistema y de qué manera. Investigando un poco nos encontramos con que los usuarios se guardan en la tabla siguiente:

Figura 3: Tabla de usuarios en Moodle

Una vez que se sabe qué tabla queremos adulterar debemos saber qué tipo de datos se guardan en ella, es decir, debemos conocer su esquema y qué columnas son las que nos interesan y cuáles no.  Se hacen resaltar los datos que quizás nos puedan interesar más, aunque podemos ver la cantidad de columnas que tienen la tabla que gestiona los usuarios en Moodle.

Figura 4: Columnas de la tabla mdl_user

La tabla sigue a continuación con el resto de columnas menos relevantes a la hora de llevar a cabo el objetivo fijado. Se observa la cantidad de datos que puede llegar a guardar Moodle sobre los usuarios de su sistema, hasta 53 columnas que, en un ataque similar podrían modificar cualquier situación, dato personal o privilegio de un usuario.

Figura 5: Hasta 53  columnas en la tabla mdl_user

Ahora que ya sabemos todo lo necesario sobre la tabla que queremos atacar, debemos analizar las consultas que realiza Moodle sobre su base de datos MySQL. Como podemos observar con el analizador de tramas de red Wireshark, el tráfico va en texto plano porque no estamos utilizando una conexión cifrada, por lo si utilizamos la técnica Network Packet Manipulation podremos modificar las consultas y tomar el control de la máquina.

Figura 6: Consultas de Moodle a MySQL en texto plano

El siguiente paso a realizar sería acceder al panel de control de Moodle y ver qué tipo de peticiones realiza cuando accedemos a la gestión de usuarios. Es decir, debemos entender el conjunto de consultas que realiza Moodle al SGBDR MySQL cuando creamos un nuevo usuario o modificamos el valor de alguno ya existente.

Figura 7: Gestión de usuarios en Moodle

Se debe de analizar las peticiones minuciosamente para encontrar la consulta en la que se realiza la inserción del nuevo usuario ya que hay multitud de ellas en el intervalo de tiempo entre la conexión al servidor MySQL y la desconexión. La instrucción elegida para esta demo en cuestión es una query SQL del tipo INSERT INTO en la tabla mdl_user y se le pasan los parámetros correspondientes recogidos del formulario web rellenado. Podríamos haber utilizado cualquier otra y modificarla completamente, pero para este ejemplo vamos a usar directamente la de inserción de nuevos usuarios. Después de analizar bien las consultas damos con ella, y es la siguiente:

Figura 8: Captura del INSERT INTO de un nuevo usuario

No cabe entera en la pantalla por lo que aquí se muestra en un editor de texto cualquiera para poder analizarla. Hay que recordar que son 53 columnas las que tiene la tabla y muchas de ellas están definidas como Not Null:

Figura 9: Consulta completa para dar de alta un nuevo usuario en Moodle

La idea principal es capturar un paquete, el cual sepamos que va a existir y modificar la consulta que lleva por la que nosotros queramos, por ejemplo una consulta UPDATE que permita modificar la contraseña o algún dato de un usuario existente con el fin de robar una cuenta.

Procedemos a ver como se podría cambiar cualquier dato de un usuario registrado en el sistema. Para realizarlo podemos crear filtros con Etterfilter. El primer filtro que se creará será el que nos posibilite cambiar la ciudad de un usuario registrado en Moodle - de forma análoga se podrá hacer para cambiarle la contraseña -. Para ello la sentencia que debemos tener en mente será:

“UPDATE mdl_user set city = 'hack3d' where username = 'zweig'”

Antes de crear el filtro debemos hacer hincapié en que los paquetes enviados a MySQL tienen el campo llamado Packet_Length, que le indica al motor de MySQL cuántos bytes debe leer y ejecutar en la base de datos. Por lo tanto, debemos localizar la consulta que sepamos que va a realizar Moodle, la cual será nuestro objetivo a adulterar, y deberemos modificar también su Packet_Length con el tamaño de nuestra consulta.

La consulta que se ha elegido como objetivo para inyectar nuestra propia consulta es la siguiente, aunque después de un análisis de las consultas podríamos haber usado un montón más que se repiten cada vez que Moodle interactúa con su base de datos:

Figura 10: Consulta elegida con Packet Length de 43 bytes

Se puede ver que su Packet_Length es de 43, el cual en hexadecimal es 2b. La consulta que queremos inyectar en el paquete es la siguiente:

UPDATE mdl_user set city = 'hack3d' where username = 'zweig'

Esta consulta tiene un tamaño de 61, que en hexadecimal es 3d. Con toda esta información ya podemos pasar a elaborar el siguiente filtro:

Figura 11: Filtro creado para modificar la consulta original a Moodle

El filtro detecta si el paquete esta destinado al puerto 3306, que es el que esta utilizando MySQL por defecto, luego decodifica el mensaje filtrando por la palabra SET SESSION. Una vez se cumplan estas dos condiciones, lo primero que hace es reemplazar el Packet_length, en el caso del paquete seleccionado es \x2b\x00\x00, por el tamaño de la que queremos inyectar, es decir \x3d\x00\x00. Después pasamos a modificar la ciudad de un usuario en concreto, al cual le pondremos como ciudad “hack3d”. De la misma forma que se puede hacer sobre ciudad lo podríamos hacer sobre cualquiera de las columnas de la tabla mdl_user. Una vez que ya tenemos el filtro llega el momento de compilarlo mediante la instrucción:

etterfilter -o md.ef2 mdl.filter2

Antes de lanzarlo, podemos echar un ojo a la tabla en cuestión de la base de datos, para comprobar el valor que tiene la columna y poder verificar si el filtro ha tenido éxito o no en nuestra prueba:

Figura 12: Ciudad antes de ejecutar el ataque

Una vez que el filtro esta compilado llega el momento de usarlo con Ettercap para realizar el ataque de MiTM entre el servidor web donde corre Moodle y el servidor donde corre el SGBDR MySQL mediante la instrucción:

ettercap -T -q -i -F mdl.ef2 -M ARP

Ahora lo lanzamos el ataque y esperamos a que Moodle interactúe con su base de datos MySQL y listo.

Figura 13: Ataque realizado

Vemos como Ettercap ha detectado un paquete que cumple con condición que le pusimos en el filtro y ejecuta los dos reemplazos programados. Volvemos a mostrar la base de datos y observamos como la columna ciudad del usuario víctima ha sido cambiada.

Figura 14: Dato cambiado en la base de datos de MySQL

Creación de un usuario en Moodle con Network Packet Manipulatrion

Una vez que ya hemos entendido los ataques podemos acabar por hackear el servidor. Para finalizar la prueba de concepto completamente nos crearemos un usuario de Moodle administrador a nuestros gusto. Para ello utilizaremos el siguiente filtro:

Figura 15: Creación de un nuevo usuario en Moodle con Network Packet Manipulation

Se ha hecho de forma análoga al anterior, esta vez el tamaño de nuestra consulta es de 230, por lo tanto remplazaremos el tamaño del original por \x6e\x00\x00. Siguiendo todos los pasos anteriores (compilación del filtro y uso del mismo con Ettercap) podremos ver el resultado en la siguiente imagen, donde hemos obtenido un nuevo usuario llamado deadp00l con la contraseña hasheada. En este momento el pentester tendrá acceso al panel de Moodle con este usuario recién creado.

Figura 16: Usuario creado correctamente en Moodle

Defensa en Profundidad en Moodle

La conclusión final es que no solo es importante que el Moodle este debidamente fortificado en cuanto a los permisos de los usuarios dentro de la plataforma, sino que para casos en los que el escenario sea como el mostrado en esta prueba de concepto se deberán cifrar las consultas SQL que se realicen contra el SGBD, en este caso MySQL, de forma análoga a como se explicó en este artículo con WordPress, ya que si una persona con intenciones poco benévolas se cuela en medio de la comunicación todo el servidor Moodle podría quedar a su merced.


Figura 17: Proteger cuentas de Moodle con Latch
Al final, mantener un escenario seguro de Moodle implica muchas cosas, no solo estas tareas explicadas en este artículo, sino realizar una fortificación completa del servidor GNU/Linux donde corra Moodle y aplicar fortificación de las cuentas de usuario, usando contraseñas robustas y segundos factores de autenticación como Latch para Moodle. La seguridad de un sistema exige aplicar protecciones a todos los niveles y que la cadena no se rompa por el menos seguro de ellos.

Autor: Jesús Largo Antón
Alumno del Master de Seguridad de la UEM

Vídeo tutoriales para proteger en 10 minutos con Latch tu servidor en Internet de: WordPress, Joomla, PrestaShop, Moodle, RoundCube, SugarCRM, SquirrelMail & Drupal

Desde hace tiempo es posible configurar Latch en una buena cantidad de frameworks populares de Internet, como las ocho plataformas que van en este título, es decir: WordPress, Joomla, PrestaShop, Moodle, SugarCRM, SquirrelMail, RoundCube y Drupal. Todas las guías detalladas de instalación y configuración están disponibles en el Canal SlideShare de Eleven Paths - donde además publicamos whitepapers y diapositivas de conferencias -. 

Figura 1: Vídeo tutoriales para proteger con Latch tu servidor de:
Moodle, Joomla, Drupal, PrestaShop, SugarCRM, SquirrelMail, RoundCube y WordPress

Con el objeto de conseguir que ofrecer mejor documentación, hemos creado unos vídeo tutoriales de configuración en estas ocho plataformas que, en menos de 10 minutos, te enseñarán a hacerlo en tu servidor y que están disponibles en el Canal Youtube de Eleven Paths.

Figura 2: Cómo proteger WordPress con Latch
  Figura 3: Cómo proteger SugarCRM con Latch
  Figura 4: Cómo proteger SquirrelMail con Latch
  Figura 5: Cómo proteger RoundCube con Latch
  Figura 6: Cómo proteger Prestashop con Latch
  Figura 7: Cómo proteger Moodle con Latch
  Figura 8: Cómo proteger Joomla con Latch

Figura 9: Cómo proteger Drupal con Latch

Si tienes tiempo hoy domingo, en 10 minutos dejas listo y protegido tu framework con Latch. Además de estos vídeo tutoriales, también tienes otros vídeos que enseñan cómo instalar Latch en otros entornos, como son:

- Cómo Integrar Latch en aplicaciones PHP
- Cómo Integrar Latch en aplicaciones .NET
- Cómo Integrar Latch en aplicaciones Java
- Cómo Instalar y Configurar Latch en Windows
- Cómo Instalar y Configurar Latch Event Monitor para Windows

Saludos Malignos!

Latch para SSH, Squirrelmail, RoundCube y nuevas apps

En Eleven Paths seguimos trabajando a toda maquina para el próximo Mobile World Congress, donde vamos a presentar muchas novedades con respecto a Latch. Para esa fecha, tendremos nuevas apps con nuevas funciones, un nuevo servicio para los desarrolladores y algún anuncio más que no os puedo contar ahora mismo.

Una nueva versión de la app de Latch

Mientras tanto, sí que os puedo decir que hemos subido nuevas apps de Latch a los markets de  apps de Windows Phone, al App Store y a Google Play con versiones en Español, que permiten a los administradores de los sitios que usan Latch personalizar el mensaje de "Cuenta bloqueada" que recibe el usuario y un nuevo menú de configuración para dar más flexibilidad al usuario. Actualmente está aprobada solo la versión de Android pero esta semana ya estarán aprobadas las otras.

Figura 1: Latch para Android ya está disponible en Español

Nuevos plugins para integrar Latch

Estamos trabajando en un buen montón de plugins e integraciones de Latch, pero esta semana ya se subieron al repositorio de código tres nuevos, que se irán completando con más esta misma semana, ya que como podéis ver tenemos en previsión el de Moodle y OpenVPN. Estos son los que ya podéis probar:

- Latch para Squirrelmail: Github de Latch para Squirrelmail
- Latch para RoundCube: Github de Latch para RoundCube
- Latch para SSH: Github de Latch para SSH

Figura 2: Nuevos plugins para Latch

La web de Latch se va a actualizar esta semana, así que en breve tendréis toda la información en la web de estos y todos los nuevos plugins y también estará disponible toda la web en Español. Seguimos trabajando a tope en Latch, pues como dicen los compañeros del trabajo... 

Figura 3: El chiste malo del "Latch us... Jesús" en Eleven Paths

Recursos de lectura sobre Latch en la web

- Cómo proteger identidades digitales con Latch
- Cómo proteger las identidades de Joomla con Latch
- Cómo instalar Latch en WordPress
- Cómo configurar Latch en un servidor FTP
- Guía de cómo utilizar Latch en 0xWord
- Guía de configuración y uso de Latch en Acens
- Como proteger aplicaciones .NET con Latch
- Probar la granularidad de operaciones en Latch con Nevele Bank
- Cómo proteger un VPS con Latch
- Cómo fortificar SSH en modo paranoico
- Cómo utilizar Latch en Recover Messages
- Ponle un pestillo a tu blog: uso de Latch en WordPress

Saludos Malignos!

Linux/Chapro.A un módulo de malware para Apache

El mundo del malware destinado al fraude online y/o e-crime no para de adaptarse para buscar nuevas formas de infectar equipos, y hacerlo desde servidores web es algo de lo más común desde hace ya más de un lustro usando kits de explotación, como el archifamoso Black Hole. La idea es sencilla, desde un servidor web comprometido - si es popular como la web del sistema postal americano mejor - lanzar un exploit que afecte al software de un cliente que se conecta e inyectar un bot para controlar la máquina desde un panel de control. Sencillo y funcional, así que se sigue haciendo.

Figura 1: Aspecto de un panel de control de Black Hole

Una de las primeras formas de conseguir comprometer los servidores web han sido los bugs de aplicación tipo SQL Injection, RFI, o incluso XSS persistentes para lanzar el exploit a los clientes. Sin embargo no se quedaron ahí, y los bugs en gestores de contenidos populares de blogs, CMS, etcétera, pasaron a ser de los más utilizados - que se lo digan a WordPress, Joomla e incluso a los Moodle -. Con este tipo de ataques se realizaron campañas de infección masiva usando los buscadores - llegando a infectar sitios de renombre como Apple.com en operaciones como Lizamoon -.

Figura 2: La web de Apple fue infectada en un ataque SQLi masivo para distribuir malware

Sin embargo, las cosas no se quedaron ahí y han evolucionado hasta aprovechar cualquier punto de apoyo para conseguir lanzar los exploits desde los servidores web. En el caso de Linux, aparecieron cosas como Linux/Snakso.A, un rootkit a nivel de kernel que modificaba las páginas web enviadas desde servidores nginx o Apache para añadir un iframe que apuntaba al kit de exploits.

El último que ha salido a la primera plana de actualidad en el mundo del e-crime es Linux/Chapro.A, un malware en forma de módulo malicioso de Apache pensado para infectar con un iframe que apunta a un kit de exploits en todas las páginas que sirve el servidor web infectado para instalar bots de Zeus en los clientes que se infecten.

Figura 3: Esquema de Linux/Chapro.A

En este caso en concreto, el kit de exploits que se estaba utilizando era Sweet Orange que, por supuesto, tiene malware y exploits disponibles para equipos con sistemas operativos Windows, Mac OS X y Linux.

Figura 4: Kit de exploits Sweet Orange

Esta idea de utilizar un módulo malicioso de Apache no es nueva, y de hecho se usan como manera de mantener un servidor troyanizado después de una intrusión, como es el caso de mod_rootme, del que ya os hablé por aquí. Si quieres revisar los módulos cargados en tu Apache, en el artículo de Fortificar Apache tienes los comandos para revisar los módulos cargados en tu servidor web.

Saludos Malignos!

Técnicas SEO para gente de moral relajada [III de VI]

**********************************************************************************************
- Técnicas SEO para gente de moral relajada [I de VI]
- Técnicas SEO para gente de moral relajada [II de VI]
- Técnicas SEO para gente de moral relajada [III de VI]
- Técnicas SEO para gente de moral relajada [IV de VI]
- Técnicas SEO para gente de moral relajada [V de VI]
- Técnicas SEO para gente de moral relajada [VI de VI]
Autores: Chema Alonso & Enrique Rando
**********************************************************************************************

Infraestructura de links: La telaraña

Una página enlaza obtendrá mayor relevancia cuanto mayor sea la relevancia que realiza el enlace. Es por eso que en muchos mensajes de spam y en muchas de las inserciones masivas de enlaces no se apunte directamente a la página que se desea subir la relevancia, sino a otras que apuntan a ella. Esto ayuda a evitar ser detectados, o al menos lo pone más difícil, ante los buscadores.

Supongamos que A es la página web que se desea subir en relevancia, para ello se añaden links desde B. A la hora de subir la relevancia los ataques a paginas C se harán o bien apuntando directamente a A o bien apuntando directamente a B. Esto, si B es una página legítima vulnerada, confundirá más si cabe a los buscadores, y mostrará a la página A apuntada desde múltiples dominios lo que la hará parecer más relevante.

Debido a esto, los hilos de salida de estas telarañas no siempre son los sitios web a promocionar. En su lugar, pueden encontrarse páginas cuyos contenidos son controlados por estos “posicionadores” y que suelen operar a modo de escaparate.


Figura 10: Spam con links iniciales de telarañas de links
Muchas veces esas webs de inicio son perfiles de usuario en plataformas web de cualquier tipo que permitan registrarse libremente ya sea por configuración normal o por un error administrativo. En el ejemplo de la Figura 10 se puede ver como se enlazan perfiles de usuario de plataformas Moodle. Como era de esperar, lógicamente, ese perfil en Moodle no es más que un anuncio publicitario en toda regla.


Figura 11: Perfil de Moodle usado para anunciar Viagra
Anuncios: Una imagen vale más que mil palabras

Moodle es una plataforma de software libre para la teleformación usada en numerosos proyectos educativos. A pesar de todas las ventajas que puedan ofrecer, en muchas ocasiones el punto débil de estos sistemas es la forma en que son administrados. No es raro que sea el propio personal docente, que ya tiene otras ocupaciones, quien gestione tanto la instalación y actualización de los sistemas como los contenidos y las cuentas de usuario.

Como resultado, es habitual que sea posible registrar cuentas de usuario sin pasar por el control de un supervisor. Por otro lado, Moodle permite a cada usuario crear su propia página web con su perfil y le proporciona muchas facilidades a la hora de incorporar contenidos HTML a dicha página. Tantas oportunidades no podían pasar desapercibidas y como se puede apreciar en la Figura 12 siguiente hay más de 535.000 usuarios de Moodle que han decidido utilizar su perfil para anunciar Viagra.


Figura 12: Cuentas de usuario de sistemas Moodle convertidas en escaparates
Algunos, incluso, aprovechan estas características para personalizar su perfil de forma que no se note que pertenecen a sistemas Moodle, como en el caso de la Figura 13, con una imagen lo suficientemente bien diseñada para simular una web.


Figura 13: Parece una página propia pero no lo es
Lo que parece una página web no es más que una imagen que ocupa toda la ventana del navegador. Ocultos tras esta imagen, se han introducido enlaces y textos con el objeto de atraer la atención de los buscadores hacia sí y hacia otras páginas.

Explotación de la infraestructura

La profesionalidad de estos autollamados posicionadores SEO hace que se creen sitios e incluso dominios para alojar y gestionar las infraestructuras que necesitan para su trabajo. Así, en el caso anterior, la URL de la imagen mostrada era: http://fredbam.com/i/screen3.gif.

Con sólo modificar el número 3 por otros valores se puede comprobar que disponen de hasta 20 imágenes distintas con las que personalizar sus perfiles:


Figura 14: Máscaras para disfrazar perfiles Moodle
Estos escaparates permiten ofrecer servicios tanto de posicionamiento en buscadores como de redirección de tráfico a otros sitios web con objeto de incrementar sus visitas.

Si controlas páginas B con relevancia, puedes promocionar muchas páginas A cobrando pasta por ello. En estos negocios, la flexibilidad es siempre un valor añadido: Hoy Viagra, mañana otro producto, pasado mañana, por qué no, partidos políticos, que se están subiendo al carro del SEO muy rápidamente.

Este ejemplo visto con plataforma Moodle se repite sistemáticamente con cualquier otra plataforma que permita crear cuentas de usuario sin un control estricto.

**********************************************************************************************
- Técnicas SEO para gente de moral relajada [I de VI]
- Técnicas SEO para gente de moral relajada [II de VI]
- Técnicas SEO para gente de moral relajada [III de VI]
- Técnicas SEO para gente de moral relajada [IV de VI]
- Técnicas SEO para gente de moral relajada [V de VI]
- Técnicas SEO para gente de moral relajada [VI de VI]
Autores: Chema Alonso & Enrique Rando
**********************************************************************************************