Parando un ciberataque a tu wordpress

Este lunes, a eso de media tarde, detectamos en la web de uno de nuestros clientes que estaba recibiendo una cantidad inusualmente alta de intentos de login fallidos. Nuestro cliente, que usa wordpress, tiene un cierto nivel de visitas digamos, importante, lo que le hace un blanco para bots y escaneadores de redes habitualmente, por lo que siempre recibe cierta cantidad de estos intentos fallidos, pero al cabo de unos minutos nos dimos cuenta de que esta vez era distinto… Estabamos en medio de uno de los mayores ataques a sitios wordpress de la historia. Este es el volumen que mostraba wordfence (el plugin de seguiridad que usamos):

Como vemos se llegaron a los 10 millones de ataques y, como dicen en su blog se trataba de un ataque distribuido masivo de fuerza bruta muy importante. De hecho indicaban que:

  • El ataque había llegado a 14.1 millones de ataques por hora.
  • El número toral de IPs involucradas fueron más de 10,000.
  • Se estaban atacando más de 190.000 sitios WordPress por hora.
  • Esta es la campaña más agresiva que nunca hemos visto por volumen de ataques por hora.

La razón que proponían como posible fuente de este ataque fue el filtrado masivo de credienciales que salió a la luz el 5 de diciembre y que dejaba expuestos millones de contraseñas nuevas que poder utilizar en un ataque de este tipo.

Así que, en medio de toda esta vorágine y recibiendo un montón de alertas, teníamos que hacer algo para proteger nuestro sitio, manteniendo el servicio y evitando que los chicos malos se nos colasen hasta la cocina.

Además de tomar las medidas habituales, nosotros escogimos un camino que nadie más podía tomar, utilizar el nuevo plugin wordpress de nomorepass que acabábamos de desarrollar y que todavía no estaba distribuido (ahora ya lo está) y que contenía una nueva opción más que interesante: “Solo permitir el acceso mediante la app”.

Con esta simple opción aunque los robots consiguieran un usuario y un password válido para el sitio no podrían entrar, porque solo se permitiría entrar a aquellos que usaron el código qr y la app para enviar sus credenciales. Esta simple medida, junto con el baneo de ips y otras medidas habituales consiguieron devolver la normalidad al sitio y, sobre todo, estar seguros de que no se podían haber colado.

Como ya os he contado muchas veces, la mejor contraseña es la que no conocemos, así evitaremos todos los ataques por ingeniería social y estaremos un poquito más seguro sin tener que cambiar – todavía – la infraestructura de acceso a nuestros sitios.

Por todo ello,  os recomiendo usar nomorepass.

El fin del hacking por ingeniería social

La mayor parte de los sistemas de acceso a las webs, correos o cualquier otro sistema informático son técnicamente lo suficientemente robustos para que utilizar métodos de fuerza bruta o criptográficos sea muy, muy complicado (hablo de webs que ya tengan ssl, ordenadores que no tengan keyloggers ni cosas de esas). De hecho los medios para romper una clave rsa que tuvo que poner la NSA (11.000 millones de dólares) no están al alcance de cualquier hacker y, desde luego, no de cualquier hacker que ande por ahí. Sin embargo, se siguen produciendo ataques, filtraciones e intrusiones en nuestras cuentas usando el método más barato de todos: la ingeniería social.

Mediante ingeniería social lo que un hacker hace es tratar de que tu mismo le entregues tus claves o, en el peor de los casos, utilizar alguna clave tuya conocida para derivar la que puede ser tu clave para ese sistema. En 2004 el New York Post publicaba un artículo en el que se describía un experimento por el que un desconocido ofrecía un dulce a cualquiera que le diese la contraseña de su correo… Y el resultado fue sorprendente, 7 de cada 10 personas entregaron la contraseña de su correo. De esta manera da igual que tengamos SSL, TLS, un sistema límpio, y todas las medidas que queramos que mediante ingeniería social cualquier atacante puede descubir nuestras contraseñas. Además, nuestro cerebro no es capaz de recordar secuencias de caracteres aleatorios, o al menos no muchas, por lo que al final solemos usar alguna heurística para tener una sola contraseña y derivar otras en base a esas. Un sistema que conduce, irremisiblemente a regalar nuestras contraseñas a cualquiera que esté interesado por ellas.

¿Cual es mi solución? Muy sencillo, que el usuario no sepa las contraseñas, no es necesario cambiar ningún sistema, ni recordar nada, ni preocuparse lo más mínimo, simplemente olvidate de las contraseñas. Para conseguir esto he creado el sistema nomorepass, que además de generarte contraseñas y almacenarlas de manera segura en tu dispositivo móvil (y solo en tu dispositivo, nada de copiarlo en la nube, ni en nuestros servidores, ni en los ordenadores) te permite enviarlas de manera segura a la web o el dispositivo que la necesita… Todo ello sin que tu tengas que saber cual es la contraseña y, por tanto, sin poder ser presa de la ingeniería social.

Llevando esto al extremo, he desarrollado un nuevo plugin para wordpress que permite hacer los registros de usuario de manera automática, sin tener que elegir un password y que lo almacena directamente y de forma segura en tu app nomorepass. Puedes hacer la prueba registrándote en este blog, simplemente pincha aquí, escribe tu nick y tu email, pincha en el icono de nomorepass y luego escanea el qr con la app usando el botón rojo. ¡voila! ya estás registrado y con tus credenciales en tu teléfono… ¡Y ni siquiera sabes qué contraseña has usado!!

Deja de usar sistemas obsoletos, de escribir las contraseñas en papeles, tener una sola contraseña (con variaciones) para todas tus cuentas o, simplemente, deja de acordarte de tus contraseñas… Usa nomorepass. Es gratis, pero si, además, quieres tener una seguridad extra puedes suscribirte, si dejas un comentario en esta entrada te enviaré un código para que puedas disfrutar de todas las funcionalidades premium durante un mes… ¿Qué esperas?

Usando google drive desde Ubuntu

Una de las cosas a los que los linuxeros estamos acostumbrados es a que las grandes empresas nos “ninguneen” constantemente y oferten servicios multiplataforma solo para windows y mac, aunque el esfuerzo de haberlos hecho para linux pueda ser mínimo. Uno de estos productos, y que uso mucho ya que tengo cuenta de empresa desde hace más de 10 años es google drive.

 

Si accedemos a la página web para descargarnos el software de google, este nos indica que no hay cliente para nuestro sistema “todavía”, y lleva diciendo esto desde hace más de cinco años, sin embargo el acceso mediante la API es realmente sencillo (yo lo uso en NoMorePass por ejemplo desde una app para móvil), por eso me extrañaba mucho esta carencia.

Pero, como siempre, la comunidad de software libre viene al rescate y ya hay algunos que han desarrollado el cliente que necesitamos. Esta es la receta para instalarlo:

sudo add-apt-repository ppa:alessandro-strada/ppa
sudo apt-get update
sudo apt-get install google-drive-ocamlfuse

Una vez instalado, hay que crear el directorio donde queremos que se sincronice (por ej. ~/google-drive) y ejecutar (como usuario):

google-drive-ocamlfuse

Esto nos abrirá una ventana en el navegador para autorizar a la aplicación y darle acceso a tu cuenta, si todo va bien terminará apareciendo esta pantalla:

Y el proceso terminará con un “Access token retrieved correctly”. A partir de este momento ya puedes montar la unidad con el comando:

google-drive-ocamlfuse ~/google-drive

Para desmontar el directorio basta con escribir:

fusermount -u ~/google-drive

Y eso es todo, yo lo he hecho y aparentemente funciona, ahora queda ver si es operativo o no…

¿Porqué el ciberataque no me importa?

Como diría Pablo Iglesias en el congreso refiriéndose a Rajoy, el “ciberataque” de estos días no me importa lo más mínimo, me trae sin cuidado o, al final, me la bufa.

¿Porqué me la bufa?

Primero, porque ese “ataque” no me afecta en lo más mínimo. Se basa en un factor de infección exclusivo de windows, utilizando una vulnerabilidad conocida hace pocos meses (excepto para la CIA) y que, por tanto, no afecta a los ordenadores Linux con los que trabajo. Así, ante la alarma causada por todos los medios de comunicación y el principio del apocalipsis cibernético augurado, yo me senté tranquilamente a ver el espectáculo.

Segundo, porque hago backups regularmente de TODO ya que no te puedes fiar de nada en esta vida y de un disco duro menos. Aunque algún muñón de colaborador le diese por venir infectado de casa con un windows y se conectase a mi red los daños que podría causar serían mínimos.

Tercero, porque no es nada nuevo, ni nada que no hayamos vivido antes. Todavía recuerdo los famosos ataques por messenger, donde toda la oficina en la que trabajaba empezó a ver como sus ordenadores empezaban a mandar infecciones a sus contactos mientras les impedía seguir trabajando. O aquella vez que cada vez que instalaba windows a mi hermana y lo conectaba a internet no pasaban ni dos minutos hasta que el virus se instalaba de nuevo y me reiniciaba el ordenador (el famoso sasser).

Y, por último, porque ahora que guardo casi todo en la nube y mis passwords están seguras en mi móvil con nomorepass, nada de esto me ha quitado ni un solo minuto de mi tiempo. ¿No hay posibilidades de infecciones en Linux? Si, claro que si, pero si un sistema operativo se ha hecho para gente sin conocimiento (como windows), lo más normal es que gente sin conocimiento lo use (y caiga más fácilmente en trampas) y eso arrastre a muchos otros que tienen que cargar con las deficiencias de un sistema que solo puede parchear un equipo determinado en un país determinado. Los usuarios de Linux suelen estar más informados y las soluciones pueden llegar de cualquier parte del mundo en cualquier momento.

Creando extensiones para los navegadores

Como ya os he comentado, desarrollando mi nuevo proyecto NoMorePass, uno de los elementos fundamentales para que se usase la app era disponer de un plugin para el navegador que permitiese interceptar las páginas con usuario/password y entrar en las mismas con el protocolo seguro de NoMorePass. Aunque en principio solo quería hacer uno para demostrar lo que se podía hacer (el de chrome, por obvias razones), al final terminé desarrollando cinco para cubrir la mayoría de las necesidades. No voy a entrar en detalles ahora sobre la tecnología subyacente, lo que voy a hacer es contaros las principales diferencias entre cada uno de los ecosistemas para los que hice las extensiones y los problemas que nos vamos a encontrar.

Todas las extensiones que he programado han funcionado (que no es poco) y todas están en javascript, así que esa parte me la voy a saltar y voy a contaros los problemas que me encontré en orden cronológico.

Chrome

Aunque, a priori, creí que iba a ser el más complicado, porque partía de una base muy pobre en lo que a extensiones se refiere, al final no fue para tanto. La documentación que dispone en la web de developers de chrome es muy completa y con ejemplos que sirven para casi todo.

Probar la extensión es sencillo, solo hay que activar el modo desarrollador en la pestaña de extensiones y cargar el directorio en el que estamos trabajando… La depuración y lo demás es muy sencillo si estamos acostumbrados a inspeccionar o depurar páginas web.

La parte más “complicada” es cuando quieres distribuir la extensión. Hay una opción que te permite empaquetarla en un archivo .crx, peeeeeero, eso no sirve para nada ya que al abrir el crx con chrome te dice que no va a instalarte nada… Así que tienes que decirles a tus probadores que se descompriman el archivo y activen la parte de desarrollador (que es un rollo de explicar) o bien pasarlo al chrome web store… Es lo que hice y puedes dejar la extensión sin publicar para que lo usen tus probadores. Muy fácil y rápido. Eso si, te pueden banear la extensión (a mi me pasó) si la revisan y ven algo sospechoso. Lo bueno es que puedes explicar lo que pasa y como funciona y si todo está ok son muy rápidos en volverte a activar la extensión. Muy contento con esta parte.

Firefox

El segundo en preferencia es, como no, Firefox. Había oído que los .xpi ya estabán obsoletos y que ahora había que hacer extensiones más parecidas a las de chrome… Y tanto! El estandar webextension está bien documentado en la MDN y, el problema, es que no es un estándar maduro del todo. Está muy basado en las extensiones chrome a las que “copian” casi todo, por lo que es muy sencillo pasar de una a otra, pero con carencias importantes (que en mi caso me hicieron reescribir gran parte de la extensión). Lo prometedor del tema es que están avanzando y según los navegadores vayan incorporando las funcionalidades que faltan vamos a un escenario de muy, muy facil adaptación.

Mozilla te ofrece la función en el AMO (addons.mozilla.org) de subir tu extensión y que te la firmen para que la puedas dstribuir entre tus probadores sin que se queje mucho el navegador. Obviamente también puedes subirla a la página pública, pero ahí el tema varía mucho…. Subí una primera versión no del todo pulida y a los dos días me rechazaron la extensión y me dieron consejos para resubirla. Lo hice a los 30 minutos de recibir la respuesta pero, según lo que dicen, me metieron en la cola de revisión de los administradores y esa cola es EXAGERADAMENTE lenta. Hoy llevo ya 32 días esperando en esa cola y estoy todavía en el número 126:

A este paso a finales de mes igual tengo ya la extensión en la página de addons de Mozilla… Completamente desesperante.

Safari

A petición de mis amigos mac-queros estudié la posibilidad de realizar una extensión para Safari. Dejadme que os diga una cosa, es un puto infierno. Apple ha cambiado la forma de construir una extensión para que tengas que escribir parte del código en Xcode (Objective-c o swift) y otra parte en javascript y que tengas que utilizar un sistema infame de empaquetado para subirlo al itunes y que aparezca disponible. El caso es que lo hice, siguiendo todas sus intrucciones, y después de conseguir que funcionase en mi mac me encontré con la maraña de certificados, firmas, perfiles, etc. que me obligaron a cambiar el proyecto un poco… Con tan mala suerte que una vez subido a itunes resulta que no funcionaba ¡¡!!

Así que, recuperé la forma antigua de hacer las extensiones, puramente en javascript y con un esquema muy parecido a las de chrome y las webextensions y un empaquetado mucho más sencillo… Y generé un archivo que Safari puede instalar sin problemas y que puedo distribuir sin problemas… Una pena que Apple se empeñe con todo su alma en hacer las cosas difíciles a los desarrolladores.

Opera

Ya con todos los deberes hechos me pareció interesante ver el nivel de compatibilidad de las webextensions entre navegadores… Y decidí hacer la extensión para Opera. Mi sorpresa fue mayúscula cuando vi que la misma extensión de chrome funcionaba sin apenas cambios en opera (quité un par de cosas del manifest.json y poco más). Así que, ole por Opera! El proceso de publicación, no obstante, sigue siendo bajo revisión y tienes que subirlo (con mucha más info de la que deseaba) en https://addons.opera.com/developer/ y ahí sigue esperando revisión… El problema es que no se en qué puesto de la cola estoy ni cuanto tiempo va a tardar en llegar a estar disponible.

Edge

Y llegamos a la gran esperanza “windowsera”, visto que, según la documentación, edge permitía un esquema muy parecido a las webextensions de firefox me lancé al ruedo y, con una máquina virtual de windows10 profesional, empecé a adaptar la extensión de firefox.

La definición correcta para las extensiones de Edge es: ¡niseteocurraporDios! Después de un montón de horas lidiando con actualizaciones del sistema, con cuelgues, con malos funcionamientos del sistema de depuración y con mi bisoñez en el sistema conseguí que la extensión funcionase en desarrollo en mi máquina… Bueno, ahora distribuirlo…

Pues no es tan sencillo, ni mucho menos, después de gastarme 90 euros (75+iva) en darme de alta como desarrollador de microsoft para reservarme el nombre de la aplicación y poder subirla a la tienda de windows.. Resulta que la tienda no admite extensiones. ¡¡¡¡¡!!!!! y, lo que es peor, para distribuir el appx que consigo generar tengo que firmarlo con unos certificados que no tengo y que solo se pueden generar con extraños comandos que no te explican de donde salen (si al menos te dijeran como hacerlo con openssl) y luego el usuario tiene que instalarse el certificado en su máquina antes de instalar la extensión.. En suma, no se cómo distribuir esta extensión ni si merece la pena….

Según microsoft esto es lo que pasa:

Así que hay que pedir por favor, por favor, que te tengan en cuenta en esta url: http://aka.ms/extension-request

Y esperando estoy…