Accede ¡Hasta 50% de descuento por aniversario! Aprovéchalo para EDcamp.¡Sube a premium!

Nos hackearon y secuestraron nuestras bases de datos.

No es broma, y la recompensa que piden por cada base de datos es de 0.15BTC, los cuales al momento de escribir este artículo ascienden a 2.100USD. Pueden hacer cuentas, fueron 3 bases de datos.

Diseño web
3 minutos
Hace 7 años
Nos hackearon y secuestraron nuestras bases de datos.

Cumplimos 9 años

formando profesionales en tecnología

No es broma, y la recompensa que piden por cada base de datos es de 0.15BTC, los cuales al momento de escribir este artículo ascienden a 2.100USD. Pueden hacer cuentas, fueron 3 bases de datos.

No se preocupen, la información de sus cuentas no fue comprometida, ni la información de EDteam. La información que secuestraron es la información de las bases de datos de las muestras de los proyectos finales de algunos de nuestros cursos. Es decir, información falsa y de acceso público que no afecta en nada el funcionamiento de la plataforma ni la información de nuestros usuarios.

Bueno, 0.45BTC menos para los atacantes.

Y, ¿cómo sucedió? Lo explico de la forma más resumida posible:

Para subir los proyectos finales nosotros utilizamos un único VPS (totalmente independiente de nuestras plataformas), pero para no afectar ni desconfigurar con las dependencias de un proyecto a otro, utilizamos docker. Al principio, pensamos que fue un ataque por fuerza bruta a nuestro usuario root. Si, si, tormentas de arena de los expertos de seguiridad informática vengan a mi. Efectivamente a ese servidor accedíamos como root y nunca deshabilitamos su login. Así que lo primero que hicimos fue deshabilitar el login de root, crear los usuarios de cada uno de los administradores del sitio y configurar MFA para los usuarios. Pero luego, analizando un poco más a fondo, me di cuenta que las únicas bases de datos que secuestraron fueron las del contenedor de postgresql, y por supuesto, comencé a revisar los archivos postgresql.conf y pg_hba.conf. Oh sorpresa, yo nunca había tocado esos archivos en el contenedor, los cuales por defecto vienen con acceso desde cualquier ip sin solicitar contraseña al usuario postgres. Sigan tormentas de arena, sigan!

La prueba más sencilla para confirmar que el contenedor estaba comprometido fue hacer un sencillo: psql -U postgres -h la-ip-del-vps y de inmediato devolvió el prompt de psql con acceso a absolutamente todo.

¿Cómo lo hacen los atacantes? Es muy sencillo, se crean una rutina en cualquier lenguaje de programación o un simple bash que ejecuta lo siguiente:

  1. Leen los nombres de todas las BD a excepción de postgresql y templates.
  2. Hacen un ciclo para ejecutar un pg_dump de cada base.
  3. Hacen un ciclo para ejecutar un DROP TABLE xxx CASCADE.
  4. Por último, crean una tabla llamada warning_ a la cual le insertan un mensaje como: "su base de datos está segura en nuestros servidores, para recuperarla solo debe transferir 0.15BTC a XXXXXXXX".

Cuando vi eso me enojé tanto que no copié el mensaje exacto y borré esa tabla de inmediato.

Claramente eso es ilegal y tiene consecuencias penales graves, pero eso ya se sale del contenido de este post, el cual escribo para que nunca subestimen la información que tienen y siempre tomen las medidas de seguridad básicas. Algunas de ellas en resumen son:

  1. Creen usuarios diferentes a root para ingresar a sus servidores.
  2. Activen el acceso multi factor (contraseña, llave ssh, entre otras).
  3. Deshabiliten el login de root.
  4. Creen usuarios diferentes al principal para su motor de bases de datos.
  5. Configuren correctamente el acceso al motor de bases de datos, para que solo puedan acceder desde las ip de la app y de administración.
  6. Nunca dejen el usuario principal del motor de bases de datos sin contraseña y ésta debe ser segura. (postgres para postgresql, root para mysql, sa para sqlserver, etc).

Cuéntenme sus experiencias con este tipo de eventos.

Comentarios de los usuarios

Pregunta a ChatEDT