El hackeo de MongoDB.
Me ha llegado este correo, a mí también me ha llegado este correo,
me imagino que si eres usuario de MongoDB, te habrá llegado este correo, ¿vale?
Y es que, dice, MongoDB está investigando un incidente sobre seguridad
que tiene que ver con acceso no autorizado a diferentes sistemas corporativos de MongoDB.
Esto incluye la exposición de metadatos de los clientes e información de contacto.
A este momento, que ellos sepan, no ha habido ningún tipo de acceso a la base de datos de MongoDB Atlas,
que básicamente es la base de datos que tienen en la nube.
Eso dicen, ¿vale?
Lo detectaron el 13 de diciembre y nada, que han estado mirando, están investigando y dicen,
¿qué es lo que deberías hacer?
Seguramente, o sea, como sabemos que ha habido algún tipo de acceso no autorizado a metadatos
de la cuenta de información de contacto, por favor, sé vigilante en ingeniería social y phishing attacks.
Y es que uno de los ataques más típicos que suelen ocurrir cuando tienen tu contraseña,
en realidad, no es utilizar tu contraseña.
No sé si sabíais esto, ¿vale?
Pero el tema es que no utilizan tu contraseña, sino que lo que hacen es escribir un correo y decirte,
hola, Antonio, wow, wow, que sepas que tengo tu contraseña que es esta.
Y he podido acceder a tal, a tal.
Si no quieres que me ponga a difundir las imágenes y todo esto, pues me tienes que pagar, ¿no?
Y muchas veces es que ni siquiera intentan utilizar la contraseña, sino que te hacen,
te dan miedo con ingeniería social de que tienen tu contraseña y que le van a utilizar.
Y así, pues, pueden enviar miles y miles de correos y extorsionarte sin ni siquiera saber realmente.
Entonces, tened cuidado.
Si os llega un correo así, que sepáis que es un tipo de ataque de ingeniería social, ¿vale?
Y dice, si todavía no lo tienes implementado, que tengas...
Bueno, como podéis ver, no da muchísima información, no dice exactamente cuál es el problema, ¿sabes?
No han llegado a decir ni cómo ha pasado.
Se supone que en MongoDB Alerts, MongoDB Alerts, aquí sí que han informado un poquito, ¿ves?
No hemos encontrado de autorización, no comentan, espero que en algún momento lo digan,
pero no han dicho ni cómo ha sido el ataque, ni exactamente cuánta información,
ni cuántos usuarios han visto afectados, nada, nada.
No se ha visto absolutamente nada de nada.
Una de las cosas que me preocupa mucho de este tipo de ataques,
a mí lo que más me preocupa es la falta de transparencia concreta de lo que ha pasado.
O sea, a mí me han notificado, pero me tengo que preocupar realmente de que han tenido acceso
porque si os fijáis aquí y os ponéis a mirar, dice, account metadata, incluido sistema de logs para un cliente.
Vale, pero han tenido acceso a la tarjeta gráfica, a la tarjeta gráfica, a la tarjeta de crédito,
porque dice, puede contener nombres, teléfonos, direcciones de correo, entre otros metadatos.
Coño, dime los metadatos exactamente, ¿qué me están robando?
Dime la verdad, ¿qué me están robando? ¿Qué me están robando? Dímelo.
¿Sabes? Este tipo de cosas, ¿no?
En realidad, lo estaban detectando en base a intentar un inicio de sesión.
Dice, cambia todo, es lo mejor ya, pero tú imagínate, ¿no os pasa que al menos una vez al mes,
una vez al mes, nos llega un correo de estos?
Yo estoy hasta los cojones, yo estoy hasta ya, hasta mis partes.
O sea, una de dos, yo creo que hay que hacer algo con esto.
Yo creo que cuando una empresa que tenga cierto nivel de ingresos,
yo creo que lo que tiene que hacer es pagar.
Tiene que pagar dinero, basta ya.
O sea, tiene que pagar dinero para que le duela, porque si no le duele, esto no para de ocurrir.
O sea, tiene que, si han accedido a datos y no han informado, lo que sea, no sé qué, yo qué sé.
Pues la primera vez, vale, un aviso.
La segunda vez, ya una multa.
Una multa que tiene que premiar a sus usuarios con dinero por haber accedido a los datos.
Es que, no sé, es que me parece que cada dos por tres pasa esto y ya es un poco...
Se supone que debes cambiar tus contraseñas cada cierto tiempo por este tipo de cosas.
Sí, no, total, y yo lo hago.
Pero también es verdad.
Yo creo que intentar no sean alarmistas con el correo, por eso metadatas mejor que dar detalles.
Hombre, ya, ya, pero no te da rabia metadatos.
Han podido acceder a los metadatos del usuario.
Pero, ¿qué metadatos? ¿Qué es eso?
Cuéntame, dime la verdad.
¿No se supone que tal información está encriptada?
Bueno, sí, debería, debería, ¿sabes?
Se supone que la agencia de protección de datos multa a las empresas, pero vete a saber.
Bueno, sí, se supone, pero yo la verdad tengo un poco dudas en este tipo de historias.
Bueno, este es el hackeo de MongoDB, que dentro de lo que hay parece ser que no ha habido accesos muy graves
y que no han podido robar información y que no han quitado dinero.
Pero, ojo, que tenemos un hackeo todavía peor.
Este sí que ha sido muy grave, es una cosa que nos podría pasar a todos y os lo voy a comentar, ¿vale?
Porque tela marinera con la que se ha liado con Ledger.
A ver, os cuento qué es Ledger porque igual no tenéis ni idea qué es Ledger.
Es como una billetera cripto, donde tú puedes meter ahí tus criptos
y se supone que deberías estar contento y feliz que no ha ocurrido nada
porque, bueno, lo desconectas y te olvidas, ¿no?
Es una billetera fría, efectivamente.
Entonces, esto es Ledger.
¿Qué pasa?
Que Ledger, obviamente, tú lo que tienes aquí con tu escrito,
tú al conectarlo con USB, pues quieres mover este dinero, ¿no?
Cuando lo conectas y todo esto, puedes iniciar sesión, mover tu escrito y todo esto.
¿Qué pasa?
Bueno, bueno, ojo, ojo, cuidado con esto.
Lo que ha pasado exactamente es el ataque más barato, pero más efectivo también de todo esto.
Aquí tenemos todo el post de Ledger que han puesto todo esto.
Lo que ha pasado aquí es que básicamente tienen el Ledger Connect Kit, ¿vale?
Que está basado también en una dependencia de Node.
En NPM te lo podías instalar.
Y teníamos que, de repente, salieron tres versiones.
La 1.15, la 1.16 y 1.17.
Y un atacante publicó código malicioso en esas versiones.
De forma que lo que hacía es que en cuanto conectabas tu billetera y tenías una de estas versiones,
lo que ocurría es que tu dinero hacía...
¡Chof!
A tomar por saco dinero.
A tomar por saco dinero.
¿Has visto tus ethereums?
Pues ahora son míos.
Eso es lo que hacía, básicamente.
Sí, sí, sí.
No, tal cual, tal cual, ¿eh?
Entonces, por fin lo han podido arreglar.
No había ningún tipo de problema.
Pero era básicamente así.
O sea, tú te conectabas y automáticamente, si era a través de esta versión,
lo que hacía era automáticamente enviar ese dinero, enviarlo a otro sitio.
Y eso es un poco lo que ha ocurrido, ¿no?
Creemos que la dirección del atacante donde el dinero llegó fue aquí, ¿vale?
Me encanta Drain.
Drain porque básicamente es lo que ocurrió, ¿no?
O sea, donde se iba el dinero era aquí.
Y que, bueno, total, como no sabemos, lo bueno es que como es descentralizado y tal,
pues sí que tenemos la dirección, pero no sabemos quién es, obviamente.
Es lo bueno y lo malo.
Las cosas son como son.
Esto de que sea descentralizado es que no vamos a poder ir y picarle a casa y preguntarle
oye, perdona, 0x65872.
No, a ver, esto no es una cosa, ahora sinceramente, esto es broma,
pero esto no es algo negativo per se.
Esto es que ha habido un ataque como, al final, es como decir,
bueno, es que un banco es malo porque te lo pueden atracar.
A ver, obviamente las cosas como son.
Esto no, esto es un delito y por lo tanto no tiene nada que ver.
Al final ha sido un hackeo que le puede ocurrir a cualquier sistema.
No tiene absolutamente nada, nada que ver con que sea peor o mejor el tema escrito, ¿eh?
De hecho, nada.
El tema es que sí que tienen su dirección, pero obviamente no saben quién es.
¿Cómo ha ocurrido todo esto?
Este es el tema, ¿no?
O sea, realmente sabemos lo que ha ocurrido, ¿no?
Han inyectado un código malicioso, han publicado tres versiones, pero ¿cómo lo han publicado?
¿Sabes cómo han publicado realmente, cómo han conseguido que eso pase?
Pues esto ha funcionado así, amigos.
Lo primero que ha ocurrido es que alguien que trabajaba o que trabajó, ¿no?
Que trabajó en Ledger y todavía tenía acceso al GitHub de Ledger.
Primer error, primer error.
Si ya no trabaja en Ledger, ¿qué haces?
Que no le has quitado acceso a esa persona.
Pero bueno, alguien que trabajaba en Ledger, que todavía tenía acceso al GitHub de Ledger,
resulta que fue atacado, ¿vale?
Fue atacado y clicó un link que tenía un email, que le pasaron un email, un phishing,
y entonces su cuenta de GitHub se vio comprometida.
Algo así, algo como esto.
¿Has sido invitado a colaborar en esto?
Venga, invita.
A mí me han llegado un correo así, así de veces.
Así, así de veces.
Me han llegado correos de estos de, te invita a que participes aquí, no sé qué.
Yo no quiero participar en nada.
Yo no sé por qué la gente le da a...
O sea, si alguien te escribe que participes en algo que tú no has pedido,
¿por qué dices que sí?
O sea, no habrá cosas por participar en la vida.
En fin.
Total, que dice, sí, quiero ver la invitación.
La aceptó, la cagó.
¿Qué pasó?
Pues que el hacker con eso tuvo acceso a la key de Ledger para publicar en NPM a través de la cuenta de GitHub.
Porque, bueno, en NPM, no sé si ahora mismo tengo el login aquí.
No, no tengo el login.
Pero en NPM ya sabéis que...
Podéis entrar por aquí.
Y, ah, amigo.
Bueno, muy bien.
Muy bien.
Second factor authentication.
Muy bien, muy bien.
Bueno, entonces, puede generar un token para meterle un continuous integration y todo esto, ¿no?
¿Qué pasó?
Pues que como tenía acceso al GitHub y en GitHub tenías la key de NPM, pues eso le permitió publicar diferentes versiones del paquete de NPM.
Y lo que hizo fue modificar el código, pushear el código y, básicamente, enviarlo directamente a NPM.
Ya está.
Ahí lo tienes.
Esto es un ataque que hemos visto un montón de veces, ¿vale?
Al final lo que hemos visto es constantemente esto, de que tienes acceso a un paquete que no deberías tener acceso, lo publicas y ya está.
Pero, guau, guau, guau, guau.
Me parece bastante, bastante bestia.
Es una pena porque el post original del usuario, ¿vale?
Lo ha quitado, lo han quitado, han quitado...
Ves que este post no está disponible porque certificaba esta historia.
Pero así ha sido la información.
Por eso, amigos y amigas, es súper importante que no aceptéis correos que no conocéis.
Eso es lo primero.
Y lo segundo es que si echáis a alguien de una empresa o deja de trabajar en una empresa, que le quitéis acceso.
Son las cosas como son, ¿eh?
Que no puede ser.
Midu, yo acabo de informar a la CTO de una empresa de ventas de entradas de un fallo de seguridad al cual puedes descargarte todas las entradas de los asistentes a los eventos que promocionan.
Y lo mejor es que no me ha contestado por LinkedIn.
Lo mejor es que se podía liar parda.
¿Quién crees que debería informar si no?
¿Me puedes informar a mí?
Hacemos un vídeo y nos forramos.
No, es broma, es broma.
¿Es broma?
¿Es broma?
¿Es broma?
En fin.
De hecho, aquí teníamos el vídeo este de Wes Boss que estaba hablando con Feroz.
Feroz que es el creador, justamente, era el creador de StandardJS.
Este hombre ahora está trabajando en temas de seguridad.
Hostia, esto es una historia muy interesante, amigos.
Esto es muy interesante.
Os voy a explicar porque esto te va a interesar y vas a flipar con lo que te voy a contar.
Mira, Feroz, este hombre, es el creador de StandardJS, que es el linter de JavaScript, que está muy chulo y no sé qué.
Pues Feroz ahora trabaja en socket.dev, que justamente trabaja en asegurarse que, básicamente, que el código que tú generas es el que realmente le llega a la gente, al usuario, para que no haya un problema en medio, ¿no?
El típico ataque en el que alguien en mitad cambia ese código de suministro, gracias.
Cadena de suministro.
Alguien en medio mete código, parchea y estás cagado, ¿no?
Bueno, entonces, esta firma, que es la de Feroz, es la persona que ha encontrado este problema.
Y ahora os cuento la historia interesante.
No solo es interesante porque ha hablado con Wes Bosch y en el podcast han estado hablando de esto, y aquí podéis ver la inyección de código Minimal Drain Value,
sino que, ojo, cuidado con esto, no solo esto, sino que Feroz tiene un curso de seguridad en la web que está increíble, que creo que es de la Universidad de Stanford.
Feroz, ciber, web, security, que os recomiendo mucho este.
Este curso, ¿ves? Feroz.
Este curso es la hostia, amigos.
Este curso es la hostia.
Mira, este curso, si os interesa la ciberseguridad, especialmente sobre web, este curso es increíble, es increíble, es gratuito,
y tiene una calidad que es que alucináis, o sea, alucináis.
Esto es del creador de StandardJS, insisto.
Y es de, si no me equivoco, es de la Universidad de Stanford, si no me equivoco.
¿Ves? Stanford University.
CS 253, seguridad web.
Son 19 clases de aproximadamente una hora 20 cada uno.
Y como podéis ver, os habla desde ataques típicos con cookies, ataques a la sesión, el típico cross-site request, el XSS, todos los ataques, el DOS, inyección de código.
Es que es increíble lo, es que es muy, muy, muy completo, ¿eh? El curso.
Y este hombre sabe muy bien de lo que habla, está muy chulo.
Así que yo no me lo he terminado porque es que es un montón, pero lo recomiendo un montón, ¿eh? De verdad, está muy, muy, muy bien.
Así que nada, le podéis echar un vistazo. Además es bastante entretenido, ¿eh?
Porque, ¿veis? Cuando habla de cookies, cookies, cookies, no sé qué, cookies, hace demos, o sea, se explica todos los ataques con ejemplos de código.
De verdad, es que me parece increíble este recurso porque que sea totalmente gratis porque es que es tremendo.
Es en inglés, también os digo, es en inglés, pero si no os importa el idioma, vais a alucinar.
Y es este hombre de aquí, que es el creador de Standard Yes.
Igual un día, no sé, si me animo, lo pasamos al español y lo hacemos aquí en vivo y en directo.
Un curso de ciberseguridad web. Está súper chulo, de verdad. O sea, es que me parece que chapó lo que hizo ahí este hombre porque tremendo.