Solucionar y prevenir los hackeos de un Drupal

 Bienvenido o bienvenida aquí otra semana más a Drupalizate, este podcast donde yo, Robert Menetray, freelance Drupal, te cuento mis cosas de créditos Drupal. Primero de todo, disculpas porque la semana pasada, el viernes pasado, tenía que haber publicado otro episodio, pero como no tenía nada grabado y como siempre voy a última hora, me tocaba grabarlo el mismo viernes por la tarde antes de publicar el episodio. El problema, que me llamó uno de los clientes, de que había un intento de hacker en unas webs y, pues, como entendeas, pues, DeepEasyData ha intentado solucionar todo eso el viernes tarde y parte del fin de semana, así que no pude grabar episodio. Es mi culpa por no tener un congelador, un frozen de episodios, que me permite tener, pues esto, la tranquilidad de que si hoy no grabó, pues puedo publicar porque me quedan dos episodios en el congelador. Tengo que ponerme con ello y tener, pues esto, dos o tres backups de episodios para ir publicando sobre la marcha. ¿Qué es lo que intentaré hacer hoy? O ya voy a publicar, voy a grabar dos o tres episodios, sólo voy a publicar el primero y este primero voy a tratar, y aprovechando el tema, sobre el tema de hackeos en webs Drupal. Cuáles son los problemas, cómo lo pueden haber intentado hackearte y cuáles son mis recomendaciones para evitar que te hackeen tu web en Drupal. Así que, empezamos con el tema. El típico problema es no tener la web actualizada. Drupal 7 actualmente, digamos, tiene soporte aún, aunque no debía tenerlo, pero lo ampliaron el año pasado un año más y ya veremos si este año lo amplían para hasta el año, o sea, el año que viene lo amplían para un año más. Esperemos que no. Drupal 7 ya tiene muchos años, pero bueno, que siguen habiendo muchas webs en Drupal 7 y la recomendación es, cuando puedas, se lleven moverte a un Drupal superior, a un Drupal 9 o un Drupal 10, pero esto de que, mientras tanto, estaría bien tener tu web en Drupal 7, la última versión de Drupal 7, no en Drupal 7 de hace tres años, o cinco meses, tener un Drupal 7 en las últimas versiones. Y lo mismo va para Drupal 8 o Drupal 9. Drupal 8 ya no tiene soporte de seguridad, debías tener un Drupal 9 mínimo, o sea, no tenías un Drupal 8, si lo tienes en tu web, está mal, ¿vale? debías dedicar tiempo o pagarle a alguien para que te lo actualice. Y si tienes un Drupal 9 similar a Drupal 7, no me vale que tengas un Drupal 9 de hace un año o de hace seis meses, debéis tener la última versión actualizada de tu Drupal 9, porque siguen contando muchas webs que no tienen actualizado al día. Después, no es sólo el Drupal como tal, el code, sino puedes tener módulos contribuidos, como cualquier web en Drupal que instales módulos hechos por la gente, puede ser que sean módulos de hace un año o dos, debes tener los módulos actualizados al día, ¿vale? Si se ha actualizado hace un mes, debes tener esa versión instalada, no la de hace un año. Y esto es porque las vulnerabilidades de código pueden ser desde el code de Drupal o pueden ser por los módulos contribuidos de otra gente. Así que lo primero de todo, lo más típico, lo que se recomienda es tener la web actualizada, puntos, acabo. Después, tema de cómo los hackers pueden encontrar de que tú tienes una web que tiene X módulos y además cómo pueden llegar a saber de que esos módulos no están actualizados y permiten un hackeo. Hay hackers que son muy listos y saben, están analizando qué boom de la vida hay, qué actualizaciones salen y cuáles tienen un riesgo de seguridad alto o moderado, y saben para qué módulos o para qué versiones de Drupal eso existe. Con lo cual, cuando tú no tienes la web actualizada, esta gente lo que hace es buscar en muchas webs lo que se llama footprints, que al final, digamos que es como una huella digital que mirando la HTML de tu web, sabes por ejemplo qué módulos tienes activados. Por ejemplo, si en el HTML de tu web salen views, por ejemplo, como clases de nombres salen Dips con views, significa que tienes el módulo views de Drupal activado. O si tienes algo de reCAPTCHA, sabes que en HTML, me refiero, saben que en tu web está activado el módulo reCAPTCHA de Google disponible para Drupal. Y esto con cualquier módulo. Si ven cosas de ese SetJapi, es que tiene el módulo SetJapi instalado. Si por lo que sea hay un fallo de seguridad en el módulo SetJapi, saben, o sea, pueden buscar qué webs tiene ese módulo instalado, pueden saber si esa web es un Drupal 7 o un Drupal 8 o un Drupal 9, y probar. Es un, ah, sé que para Drupal 8 y para una versión de hace un año de SetJapi había este fallo de seguridad que se explotaba de esta forma. Lo intento. Ah, que puedo explotarlo, vale, pues ya está, la web tengo acceso para hacer cosas dentro. Ah, que no puedo, ah, pues debe estar actualizada, pues nada, paso a la siguiente web porque tengo varias, porque a fin a esta gente normalmente no van enfocados a joderte solo a ti, a tu web. Van enfocados a encontrar webs vulnerables y aprovecharse de ello. Así que, como digo, ten tu web actualizada para no ser objeto de esos ataques, ¿vale? Después es el tema de, ya no de código como tal, sino de malas configuraciones. Y sobre todo, más configuraciones que den acceso a usuarios a hacer cosas. Me he encontrado cosas raras en algunas webs, como puede ser, que fue un caso un poco extraño, de la web permitía que cualquier persona que hacía un usuario se dice de alta en la web, vale, formular de registro estaba abierto para cualquiera, tú ponías un nombre de un mail y ya te registrabas automáticamente, y además se juntaba con que el usuario registrado, sin tener ningún rol especial, solo por estar registrado, tenía acceso a editar páginas de la web. Y en ese proyecto era cualquier página, de cualquier, de la web en deda. Podían editar la home, podían editar los artículos del blog, podían editar cualquier cosa. Con lo cual no fue un jogueo como tal, fue una mala configuración de la gente que les desarrolló esa web y es un... cualquier persona podía acceder y editar contenidos o crear contenidos nuevos. Y en ese caso, por suerte, solo fue que puse en enlaces y algo he hecho al script, pero bueno, no fue a más. Se recuperó un backup antiguo y se quitó de que la gente pudiese registrarse en esa web. Por eso, cuidado con tener usuarios registrados que permitan... que tu configuración permita que hagan cosas. Eso lo vinculo, por ejemplo, en una de las últimas aletas de seguridad en Drupal 9. Salió de que había un bug con Twig. Twig es el sistema de plantillas en Drupal, o sea que el bug no era de Drupal propiamente dicho, sino que era del sistema Twig. Claro, Drupal usa Twig, con lo cual digamos que es vulnerable. El parche justamente era para evitar que la gente con permisos para editar plantillas Twig la pudiese liar tanto como hasta ahora. Eso significa que si tenías un usuario que podía tocar ficheros de código Twig, la podría liar bastante y aparte también, aunque no pudiera tocar ficheros Twig, pero pudiera acceder a módulos que permitiesen modificar cosas de Twig, como por ejemplo modificar virus. El módulo virus permite interactuar con tokens, con... no es bien una plantilla Twig, pero permite ejecutar código Twig dentro de virus. Así que lo mismo, si tienes usuarios que pueden editar virus y esos usuarios por algún motivo les han hackeado la contraseña, o es un usuario, imagínate que es alguien de tu empresa, que has dejado allí y que lo has echado de la empresa, pero después de un año aún sigue teniendo acceso, te la podría liar. Así que, recomendaciones, tener usuarios muy limitados en permisos y si hay un usuario que tiene permisos porque es administrador o editor o lo que sea, si ese usuario ha dejado la empresa y no tiene que estar tocando la web, bloquea o elimina ese usuario. Bueno, por eso, cosa ten en cuenta. Después, también similar, podemos tener en el sistema de ficheros de Drupal, podemos tener usuarios que puedan crear nodos, por ejemplo, o editar nodos y en esos nodos se permiten subir ficheros. Lo típico son imágenes y pdfs, que eso digamos es inuoco, no pasa nada. O por ejemplo, podemos tener que el usuario anónimo en el formulario de contacto pueda juntar su currículum, por ejemplo, porque estás buscando gente y quieres que la gente vaya a tu web, en el formulario suba su currículum, que normalmente es un pdf o un doc, o sea un Word, y ya está. El problema es que si en esos formularios de subir de ficheros, permites que suban cualquier fichero y no se limita por extensión, podrían subir ficheros de código, de por ejemplo Python o PHP, o lo que pueda llegar a ejecutar tu servidor. Yo me he encontrado ficheros de código de Python en un servidor, por suerte en ese servidor no se puede ejecutar Python. Pero lo que voy es que se pueden intentar subir fichos al servidor y si el servidor está mal configurado o permite ejecutar esos ficheros, por ejemplo, si forman de PHP, Drupal funciona con PHP, y si el servidor da respuesta para la URL de ese fichero, cualquier persona puede subir cualquier script y ejecutarlo, y hacer básicamente cualquier cosa, desde autologarse como usuario admin, cambiar la contenida del admin, eliminar usuarios, crear usuarios nuevos, modificar contenido, hacer lo que literalmente lo que cualquier admin pudiese hacer. Así que mucho cuidado con tener formularios que permitan ficheros y ya sobre todo que sean ficheros que no estén limitados por extensión de fichero. Después, temas de, por ejemplo, ataques a lo que ya no es Drupal como tal, sino a lo que es la base de datos. Puede ser que, por ejemplo, tengamos en el servidor de producción o en el de preproducción, que también me he encontrado intentos de hackeo en servidores de preproducción más que de producción. Puede ser que tengas, por ejemplo, un adminer o un perchip en mi admin que te permiten logearte y interactuar con la base de datos. No interactúas directamente con Drupal, interactúas con la base de datos. Aquí puede ser que el hacker intente por fuerza bruta probar usuarios y contraseñas directamente contra los logins de perchip de mi admin, por ejemplo. Aquí va a depender más que nada de cómo es el servidor, o sea, cómo está configurado el servidor y a quién permite conectar por perchip de mi admin o por adminer o por ese tipo de herramientas. Esto no lo vamos a tener en cuenta porque si alguien tiene acceso y se puede logear en estas herramientas o tienes directamente un perchip de mi admin sin usuario y contraseña, sino que sólo con la url puedes acceder dentro, pues cualquier persona podría editar o modificar o exportar datos de la base de datos. Y aquí quizá exportar datos no es un hackeo como tal, pero si tienes mails de personas, teléfonos de personas, DNIs de personas y datos varios, pues digamos no es un hackeo, pero bueno, son datos sensibles que por ley te pueden meter multa. Así que cuidado con esto. Similar con lo de perchip de mi admin, me encontré webs que tienen backups accesibles desde internet. Esto pasa mucho cuando haces un backup manualmente y lo dejas en la raíz de la web y el servidor permite que cualquier fichero, o sea, es entre comillas una mala práctica del programador y es entre comillas una mala configuración del servidor. Si el servidor permite cualquier descarga de un fichero.sql, por ejemplo, pues está permitiendo de que un fichero que alguien ha dejado en la raíz de la web o en un directorio, cualquier hacker que pueda llegar a obtener esa url se puede descargar una copia, un backup de la base de datos entera. Y lo mismo de antes, que tendrá mails de usuarios, nombres, la contraseña está encriptada, pero podría intentar desencriptar la contraseña. Bueno, es un riesgo, digamos, de datos alto. Vale. Similar con esto, puede ser de que no es que el webmaster haya hecho un backup en la raíz, sino que tengamos, por ejemplo, un módulo como el backupamigrate que te genera un directorio y cada día o cada x tiempo está generando backups en ese directorio. Si el servidor está mal configurado y, por ejemplo, no hay un htaccess o no está bloqueada, que esa ruta, ese directorio, no sea accesible por internet, es el mismo caso. Puede llegar un hacker y saber que la dirección por defecto de backupamigrate es esta, intentar obtener datos de ese directorio y, ah, que obtengo la lista de fichos que hay dentro, ah, perfecto, me bajo los ficheros, o sea, me bajo el backup que hay dentro. Así que cuidado con eso también. Y después está el tema de que puedes tener las configuraciones de los directorios de tu propia web, los permisos de esos ficheros, cualquier persona pueda modificarlos, o cualquier persona, o mejor dicho, la web propia pueda modificar los códigos de su misma web. Una cosa es que subas el código de tu web y que la web pueda como mucho crear ficheros en un directorio en SiteDefaultFiles para subir fichos de imágenes o PDFs. Y otra muy distinta es que la misma web tenga permisos para que el PHP modifique ficheros de código de módulos o del core. Esto es un poco polémico porque en un futuro se prevé de que Drupal va a permitir actualizaciones automáticas directamente en producción. A mí esto justamente a mí no me gusta. ¿Por qué? Porque significa que la propia web tiene permisos para modificar los propios ficheros de la propia web. Significa de que si un hacker entra te puede modificar cualquier fichero. Yo soy más de que el servidor no permita que la web tenga acceso a modificar o crear ficheros en los directorios que son de código, que no son directorios de SiteDefaultFiles. Así que es una cosa a tener en cuenta. Bueno, dicho todo esto, recomendaciones que hago yo para intentar que el hack no sea tan bestia. Intentar minimizar estos riesgos. El primero, tener la web actualizada, por supuesto. El segundo, tener backups diarios y de varios días. No sólo tener el último backup. Primero todo porque el hacker puede haberte infectado hace una semana y te has dado cuenta ahora. Y los backups de hace una semana ya están infectados y te comes el problema con patatas. Me he encontrado gente que directamente es que no tienen ni backup. Así que cuando te hagan, haces la limpieza como puedas. Después, si miras el tema de backups, y con backups me refiero al tema de backups de código y de base de datos y de ficheros, o sea de imágenes y PDF, o sea de todo, no sólo de la base de datos. Me refiero a backups de todo, porque hay gente que piensa que no sólo con MySQL. No, porque te van a haber infectado y no sabes en dónde. Después, ya no backups como tal, aunque se puede interpretar que casi lo es, es el tema de que el código esté en Git. Usas la herramienta Git para hacer los deploys en pre-producción y en producción y el código, las modificaciones de código, Git te va a marcar qué modificaciones en el código se han hecho, al menos en los directorios que estás configurado en el Git para tener en la gestión con Git. Esto lo veo mucho porque en webs que no tienen Git, que trabajan con FTP, cuando alguien te modifica código PHP de la web, no sabes nada, o sea, no sabes ni qué código modificado ni en dónde. Con Git, al menos, puedes de forma muy simple con un comando ver qué código se ha modificado, qué módulo se ha modificado, aunque no puedes saber en qué fecha, después puedes ir por el video y ver que este fichado se ha modificado a esta fecha en concreto. Git no lo te va a decir por defecto, pero hay formas de obtenerlo. Pero lo que voy es de que, de forma simple, cuando ves que te han hackeado y está todo por Git, puedes revertir los cambios y dejar el código 100% como estaba antes. Así que es una forma rápida de prevenir que el hacker vaya más. Así que, hiper recomiendo que todo lo tengas por Git. Otro tema puede ser de que tengas una web que está en un servidor con varias webs al mismo tiempo. Si tienes, por ejemplo, un servidor con cinco webs y hay una de las webs, solo una, que no está actualizada, y por el motivo que sea hacker la encuentra y te hackea esa web, depende de cómo esté configurado tu servidor puede escalar y puede llegar a que esa web modifique código de las otras webs que sí que están actualizadas y seguras. Con lo cual, al final, el hacker o de una web vieja que no está actualizada, que puede no ser una cosa ni que sea un Drupal, puede ser un web que tengas en el mismo servidor, permite de que el hacker pueda tener acceso al código de las otras webs, a modificar el código de otras webs, o directamente a bajarse un backup de la base de datos de los Drupals. Con lo cual es un riesgo de seguridad alto. Mi recomendación, tener una web para cada servidor. Webs separadas. No tener un servidor con muchas webs al mismo tiempo, porque a la que te hackeen una web, te han podido hackear todas las que tengas ahí dentro. Ya, hoy en día, al final, tampoco es tan caro tener un servidor para cada web. Y lo mismo va para el tema de entornos de preproducción y producción. Puede ser que sea más fácil hackeable un entorno de preproducción, porque por temas de riesgo de seguridad, por ejemplo, el PHP Miami no se tiene tan en cuenta, pero es el mismo servidor que tenemos en producción, con lo cual estamos vendidos igualmente. Y después también recomiendo mucho el tema de los logins de usuarios, intentar limitarlos. En Drupal por defecto te limita, o sea, cuando, a ver cómo explico. Hay intentos ataque de fuerza bruta, que hay un bot que intenta lograrse con el usuario admin, o digamos, variaciones de admin, y con contraseñas de admin admin, admin 1, 2, 3, 4, y con palabras varias, o con el nombre de la empresa, o cosas de estas. Al final es un ataque de fuerza bruta porque es un bot que intenta lograrse de mil maneras distintas, a ver si una de ellas cuela, y puede lograrse como admin. Drupal tiene por defecto un bloqueo de intentos. Si hay muchos intentos de golpe, va limitando hasta que llega un punto que bloquee al usuario. Pero aún así, yo recomiendo que tengas un sistema de capture. Eso significa que los bots van a tener más problemas para intentar enviar estos formularios, porque el capture va a saltar antes y no va a permitir que se envíen estos formularios. Así que te evitas muchos problemas de bots. Así que recomiendo mucho tener un sistema de capture bueno. Hice un episodio un tiempo atrás, justamente en este podcast, hablando de temas de capture y de temas de lucha contra anti-bots. Así que si te interesa el tema, lo buscas y te lo escuchas. Y pocos más. Después, temas de hackeos. ¿Qué puede intentar buscar un hacker cuando te está intentando hackear tu web? Puede ser que te intente, digamos, extorsionar. Si no tienes backups, bueno, pues es bueno, págame y dejo de hackearte y te devuelvo la web como estaba antes. No he conocido ningún caso de estos, pero bueno, sé que puede darse el caso. Los casos que son más típicos es aprovechar la web para poner contenido no real, por ejemplo, webs de viagra o webs de mierdas. Ya sea porque ponen el contenido en tu web, donde hay en la sede de compra, webs externas, o porque directamente tu web hace redirecciones y el usuario que llega a tu web es redirigido a, por ejemplo, a comprar viagra, como por ejemplo lo decía. Menos contado, comprar viagra, cosas de juguetes sexuales, cosas de drogas, también había uno, y otros que directamente hacían redirecciones a webs con publicidad. Si tu web está bien posicionado en SEO y tienes bastante tráfico a tu web, pues al hacker le interesa, porque al final es una web de que anda, mía, tenía más o menos tráfico y todo el tráfico que me llegue, o el 50% del tráfico que me llegue, lo derivo a otra web donde tengo publicidad o tengo algo para que la gente pague. O puedo suplementarte la identidad, y por ejemplo, si es una web de movimientos de alquiler de coches, lo redicciono a una competencia o a otra web de alquiler de coches, o a una web falsa, haciéndome pasar como que alquilo coches y que la gente me pague desde allí. O sea, subventación de identidad. Así que cuidado. Cosas que he visto con este tipo de sistemas, algunas veces lo hacen 100% veces, o sea, cada usuario que entra es redigido o ve el contenido falso, y otras veces lo hacen de forma aleatoria. O, por ejemplo, el usuario anónimo sí que ve esos cambios, pero el usuario administrador o el usuario logueado no los ve. Con lo cual, la gente que está editando esa web, como Drupal, tiene unas dos semanas que te mantiene logueado en la web, digamos que mi cliente no se da cuenta de que le han hackeado porque él lo ve todo normal. Pero el usuario anónimo que entra allí ve que la web hace cosas raras, que lo redirige. Así que cuidado con esos temas que a veces no siempre te das cuenta el mismo día que te hackean. Pues te da un tiempo hasta que un cliente de mi cliente, o sea, un usuario de la web se queje de, ¡ey, mira que la web está haciendo esto! ¿Esto es normal? Vale, que lo tengas en cuenta. Después, aparte de esto de hacer redirecciones, puede ser que lo que les interese es solamente poner enlaces en tu web. Eso es para el tema de blackseo. Hackean webs, ponen enlaces para hacer link building, link building feo, pero bueno, te enlazan tu web a la suya, o a una de las suyas, o a una de un cliente que les ha pagado para obtener enlaces. Si tienes un web con muy buen SEO, digamos que es una mala práctica porque puedes estar enlazando a webs, por ejemplo, nuevas que vendan, pongamos el caso de siempre, lo de Viagra, por ejemplo, intentar posicionar esas webs a costa de tu reputación en tu web, lo cual es un problema también. Y esto también va para el tema de que pueden crear contenido, pueden crear comentarios y esos comentarios normalmente van con enlaces a la web del hacker o, como digo, a alguien que le haya pagado para enviar enlaces allí. Y por otra cosa, básicamente es esto, extorsión, después redirecciones o poner contenido haciéndose pasar por ti, o obtener enlaces. Son los hackeos más comunes que he visto, o sea, los motivos de hackeo más comunes que he visto. Bueno, perdón, y también me dejo, puede ser que intenten modificar precios de un e-commerce para hacer envíos de e-commerce con descuento. Eso solo lo vi una vez y supongo es porque era un e-commerce que no tenía productos físicos, con lo cual te puedes descargar los cursos de forma gratuita, porque si fuera un e-commerce de productos físicos y el hacker fuera tan gilipollas de poner sus datos para que le enviesen el hackeo, pues 2 más 2 son 4. Me refiero de si me han hackeado la web, han puesto que esto que valía sin iguales, me vale 2. Y solo una persona se lo ha enviado a su casa, pues tiene pinta que el hacker es este tío. Como digo, no pasó, sino que era una cosa de descargas online y se descargara un contenido premium de esa web online. Pero bueno, esto que nadie puede pasar, de que te modifiquen cosas de e-commerce. Y creo que nada más. Creo que más o menos ha quedado claro. No me he hecho guión, así que ha ido un poco sobre la marcha. Si tienes más dudas de estos temas, pues me comentas. Por cierto, cuando no tienes backups, hacer una limpieza de tu web es un dolor de culo. O sea, limpieza de base de datos para saber qué cosas han tocado y cuáles no. Si lo han hecho desde Drupal, puedes llegar a saber qué nodos han tocado, porque ves qué páginas, ves la fecha de modificación. Pero si lo han hecho directamente en base de datos, eso no queda registrado en qué fecha han tocado qué. Así que puede ser muy complejo adivinar qué han tocado. Se puede hacer una limpieza de base de datos, yo lo he hecho en algunos casos. A ver, casi siempre es porque ponen el mismo código de JavaScript o el mismo código de enlace en muchas páginas, con lo cual les hacen una consulta más o menos simple. Pero nunca hasta 100% seguro de haber hecho una limpieza al 100%. Siempre te puedes haber dejado algo. Si tienes un backup, lo recomendable es restaurar como estaba antes. Después, si es de código, lo mismo. Si lo tienes todo por git, puedes revertir el código por git o restaurar un backup de código que tenías antes. Y lo mismo va para los ficheros. Si tienes ficheros de imágenes, sobre todo cuando son webs donde hay mucho usuario subiendo contenido y esto que tiene imágenes, PDFs y estas cosas, puede ser muy recomendable comprar el backup que tenías de esos ficheros con el que tienes ahora y ver qué ficheros nuevos se han creado. Y si son ficheros, digamos, susceptibles de que sean de código o de hackeo, pues analizarlos con más detenimiento. Y creo que nada más. Si hay cualquier cosa, me comentáis por LinkedIn o en mi web en menetray.com me contactáis por ahí. Nada, buen fin de día. Nos vemos.