¿PUEDE SER HACKEADO Y LUEGO PROCESADO POR ELLO?
Criptomonedas señores del crimen. Parches de seguridad para VMware, OpenSSH y OpenSSL. violador medico Busted. Es que una error o una característica?
Haga clic y arrastre en las ondas sonoras de abajo para saltar a cualquier punto. Tú también puedes escuchar directamente en Soundcloud.
Con Doug Aamoth y Paul Ducklin
Música de introducción y final de Edith Mudge.
Puedes escucharnos en SoundCloud, Podcasts de Apple, Podcasts de Google, Spotify, Stitcher y en cualquier lugar donde se encuentren buenos podcasts. O simplemente suelta el URL de nuestro feed RSS en tu cazador de vainas favorito.
LEER LA TRANSCRIPCIÓN
DOUG. Parches, correcciones y señores del crimen: ¡vaya!
Ah, y otro administrador de contraseñas en las noticias.
Todo eso, y más, en el podcast de Naked Security.
[MÓDEM MUSICAL]
Bienvenidos al podcast, todos.
Soy Paul Ducklin; él es Doug Aamoth...
..creo que lo entendí al revés, Paul: *Yo* soy Doug Aamoth; *él* es Paul Ducklin.
Paul, nos gusta empezar el programa con un Esta semana en la historia de la tecnología segmento.
Y me gustaría presentar algo de la historia muy reciente.
Esta semana, el 06 de febrero de 2023, nuestro propio Paul Ducklin...
PATO. [ENCANTADO] ¡Woooooo!
DOUG. ...publicó una entrevista con periodista de tecnología Andy Greenberg sobre su nuevo libro, "Rastreadores en la oscuridad: la caza global de los señores del crimen de las criptomonedas".
Escuchemos un clip rápido...
[PICADA MUSICAL]
PABLO PATO. Ciertamente ha habido una fascinación durante décadas para decir, "¿Sabes que? ¿Esto del cifrado? En realidad es una muy, muy mala idea. Necesitamos puertas traseras. Necesitamos poder romperlo, alguien tiene que pensar en los niños, etc, etc.
ANDY GREENBERG. Bueno, es interesante hablar sobre las puertas traseras criptográficas y el debate legal sobre el cifrado que ni siquiera las fuerzas del orden pueden descifrar.
Creo que, de alguna manera, la historia de este libro muestra que a menudo eso no es necesario.
Quiero decir, los criminales en este libro estaban usando encriptación tradicional.
Estaban usando Tor y la Dark Web.
Y nada de eso fue descifrado para reventarlos.
[PICADA MUSICAL]
PATO. Sé que diría esto, Doug, pero recomiendo escucharlo. Podcast.
O, si prefieres leer, ve y mira la transcripción, porque…
…como le dije a Andy al final, fue tan fascinante hablar con él como leer el libro en primer lugar.
Recomiendo encarecidamente el libro, y tiene algunas percepciones asombrosas sobre cosas como las puertas traseras criptográficas que provienen no solo de la opinión, sino de investigar cómo las fuerzas del orden han tratado, aparentemente de manera muy efectiva, con los delitos cibernéticos, sin necesidad de pisotear nuestra privacidad tal vez como tanto como algunas personas creen que es necesario.
Entonces, algunas ideas fascinantes allí, Doug:
Rastreadores en la oscuridad: la caza global de los señores del crimen de las criptomonedas
DOUG. Fíjate eso… eso está en la norma Fuente de podcast de Naked Security.
Si está recibiendo nuestro podcast, ese debería ser el justo antes de este.
Y pasemos ahora a una ronda relámpago de arreglos y actualizaciones.
Tenemos OpenSSL. tenemos VMware y tenemos OpenSSH.
Empecemos con VMware. Pablo:
¿Usuario de VMware? ¿Preocupado por el "ransomware ESXi"? ¡Revisa tus parches ahora!
PATO. Esto se convirtió en una gran historia, creo, debido a un boletín que publicó el CERT francés (Equipo de Respuesta a Emergencias Informáticas) el viernes de la semana pasada.
Entonces. Eso sería el 03 de febrero de 2023.
Simplemente le dijeron cómo era: “Oye, existen estas vulnerabilidades antiguas en VMware ESXi que podrías haber parcheado en 2000 y 2021, pero algunas personas no lo hicieron, y ahora los delincuentes están abusando de ellas. Sorpresa, sorpresa: el resultado final es igual al ransomware”.
No lo expresaron así... pero ese era el propósito del boletín.
Se convirtió en una especie de tormenta de noticias de [VOZ DE SOBRESALTO], “¡Oh, no! ¡Error gigante en VMware!”
Parece como si la gente estuviera infiriendo, “¡Oh, no! ¡Hay un nuevo día cero! ¡Será mejor que tire todo y vaya a echar un vistazo!
Y, de alguna manera, es peor que un día cero, porque si corre el riesgo de sufrir el ataque de esta pandilla cibernética boutique en particular, que termina en ransomware...
… has sido vulnerable durante dos años.
DOUG. Un día de 730, en realidad...
PATO. ¡Exactamente!
Así que escribí el artículo para explicar cuál era el problema.
También descompilé y analicé el malware que estaban usando al final.
Porque creo que lo que mucha gente estaba leyendo en esta historia es: “Vaya, hay un gran error en VMware y está generando ransomware. Entonces, si estoy parcheado, no necesito hacer nada y el ransomware no sucederá”.
Y los problemas son que estos agujeros se pueden usar, esencialmente, para obtener acceso de root en cajas ESXi, donde los delincuentes no tienen que usar ransomware.
Podrían realizar robos de datos, envío de spam, registro de teclas, criptominería, {insertar el ciberdelito menos favorito aquí}.
Y la herramienta ransomware que utilizan estos delincuentes, que es semiautomática pero se puede usar manualmente, es un codificador de archivos independiente que está diseñado para codificar archivos muy grandes rápidamente.
Por lo tanto, no están completamente encriptados: lo han configurado para que encripte un megabyte, salte 99 MB, encripte un megabyte, salte 99 MB...
…así que atravesará un VMDK (archivo de imagen de máquina virtual) de varios gigabytes o incluso un terabyte muy, muy rápido.
Y tienen un script que ejecuta esta herramienta de cifrado para cada imagen de VMware que puede encontrar, todo en paralelo.
Por supuesto, cualquiera podría implementar esta herramienta en particular *sin romper la vulnerabilidad de VMware*.
Entonces, si no está parcheado, no necesariamente termina en ransomware.
Y si está reparado, esa no es la única forma en que los delincuentes podrían entrar.
Por lo tanto, es útil informarse sobre los riesgos de este ransomware y cómo puede defenderse de él.
DOUG. Ok muy bien.
Entonces tenemos un pokeable error de memoria doble libre en OpenSSH.
Eso es divertido de decir...
OpenSSH corrige el error de memoria doble libre que se puede introducir en la red
PATO. Lo es, Doug.
Y pensé: "Es bastante divertido de entender", así que lo escribí en Naked Security como una forma de ayudarlo a comprender algo de esta jerga de errores relacionada con la memoria.
Es un problema bastante esotérico (probablemente no te afectará si usas OpenSSH), pero sigo pensando que es una historia interesante, porque [A] porque el equipo de OpenSSH decidió que lo revelarían en sus notas de lanzamiento, "es no tiene un número CVE, pero así es como funciona de todos modos”, y [B] es un gran recordatorio de que los errores de administración de memoria, particularmente cuando se codifica en C, pueden ocurrir incluso a programadores experimentados.
Este es un doble libre, que es un caso en el que terminas con un bloque de memoria, entonces lo devuelves al sistema y dices: “Puedes darle esto a otra parte de mi programa. He terminado con eso."
Y luego, más adelante, en lugar de usar ese mismo bloque nuevamente después de que te hayas dado por vencido (lo que obviamente sería malo), devuelves la memoria nuevamente.
Y suena como, “Bueno, ¿cuál es el daño hecho? Solo te estás asegurando.
Es como volver corriendo del estacionamiento a tu apartamento y subir y comprobar: "¿Realmente apagué el horno?"
No importa si regresas y está apagado; solo importa si regresa y descubre que no lo apagó.
Entonces, ¿cuál es el daño con un doble gratis?
El problema, por supuesto, es que puede confundir el sistema subyacente, y eso podría llevar a que la memoria de otra persona se administre mal o se vuelva inmanejable de una manera que los delincuentes puedan aprovechar.
Entonces, si no entiendes cómo funciona todo eso, entonces creo que esta es una lectura interesante, tal vez incluso importante...
…a pesar de que el error es razonablemente esotérico y, hasta donde sabemos, nadie ha descubierto una forma de explotarlo todavía.
DOUG. Por último, pero no por ello menos importante, hay un problema de alta gravedad error de robo de datos en OpenSSL eso ha sido arreglado.
Y recomendaría a las personas, si son como yo, razonablemente técnicos, pero reacios a la jerga...
…las notas oficiales están repletas de jerga, pero, Paul, haces un trabajo magistral al traducir dicha jerga al inglés sencillo.
Incluye una explicación dinamita de cómo funcionan los errores de memoria, que incluye: desreferencia NULL, desreferencia de puntero inválido, desbordamiento de búfer de lectura, use-after-free, double-free (de lo que acabamos de hablar) y más:
OpenSSL corrige el error de robo de datos de alta gravedad: ¡parche ahora!
PATO. [PAUSA] Bueno, me has dejado un poco sin palabras, Doug.
Muchas gracias por sus amables palabras.
Escribí esto por… Iba a decir dos razones, pero más o menos tres razones.
La primera es que OpenSSH y OpenSSL son dos cosas completamente diferentes, son dos proyectos de código abierto completamente diferentes ejecutados por diferentes equipos, pero ambos se usan mucho más.
Por lo tanto, el error de OpenSSL en particular probablemente se aplique a usted en algún lugar de su propiedad de TI, porque es casi seguro que algún producto que tiene en algún lugar lo incluye.
Y si tiene una distribución de Linux, es probable que la distribución también proporcione su propia versión: mi Linux se actualizó el mismo día, por lo que desea ir y comprobarlo usted mismo.
Así que quería que la gente se diera cuenta de los nuevos números de versión.
Y, como dijimos, estaba esta vertiginosa carga de jerga que pensé que valía la pena explicar... por qué incluso las cosas pequeñas importan.
Y hay un error de alta gravedad. (no voy a explicar confusión de tipo aquí: vaya al artículo si desea algunas analogías sobre cómo funciona).
Y este es un caso en el que un atacante, tal vez, puede desencadenar lo que parecen ser comparaciones de memoria perfectamente inocentes en las que solo comparan este búfer de memoria con ese búfer de memoria...
…pero desvían uno de los búferes y, he aquí, pueden averiguar qué hay en *su* búfer comparándolo con cosas conocidas que han puesto en *los suyos*.
En teoría, podría abusar de un error como ese en lo que podría llamarse una especie de Heartbleed.
Estoy seguro de que todos recordamos que, si nuestras carreras de TI se remontan a 2014 o antes, el Error OpenSSL Heartbleed, donde un cliente podría hacer ping a un servidor y decir: "¿Sigues vivo?"
“Heartbleed heartache”: ¿realmente deberías cambiar todas tus contraseñas de inmediato?
Y devolvía un mensaje que incluía hasta 64 kilobytes de datos adicionales que posiblemente incluían secretos de otras personas por error.
Y ese es el problema con los errores de fuga de memoria, o posibles errores de fuga de memoria, en productos criptográficos.
Ellos, por diseño, generalmente tienen mucho más que ocultar que los programas tradicionales.
Entonces, ve y lee eso y definitivamente parchea tan pronto como puedas.
DOUG. No puedo creer que Heartbleed fuera 2014.
Eso parece... Solo tenía un hijo cuando salió eso y era un bebé, y ahora tengo dos más.
PATO. Y aún así seguimos hablando de eso...
DOUG. ¡En serio!
PATO. …como un recordatorio definitorio de por qué un simple desbordamiento del búfer de lectura puede ser bastante catastrófico.
Porque mucha gente tiende a pensar: "Oh, bueno, seguramente eso es mucho menos dañino que un desbordamiento de búfer de *escritura*, donde podría inyectar shellcode o desviar el comportamiento de un programa".
Seguramente, si solo puedo leer cosas, bueno, podría obtener sus secretos... eso es malo, pero no me permite tener acceso a la raíz y tomar el control de su red.
Pero como han demostrado muchas violaciones de datos recientes, a veces poder leer cosas de un servidor puede revelar secretos que le permiten iniciar sesión en un montón de otros servidores y hacer cosas mucho más malas.
DOUG. Bueno, esa es una gran transición sobre cosas traviesas y secretos.
Tenemos una actualización de una historia de Pasado de seguridad desnuda.
Puede recordar la historia de fines del año pasado sobre alguien que infiltró una empresa de psicoterapia y robó un montón de transcripciones de sesiones de terapia, y luego usó esa información para extorsionar a los pacientes de esta empresa.
Bueno, se dio a la fuga... y estaba recientemente arrestado en Francia:
Sospechoso de extorsión de psicoterapeutas finlandeses arrestado en Francia
PATO. Este fue un crimen verdaderamente feo.
No solo violó una empresa y robó una gran cantidad de datos.
Violó una empresa de *psicoterapia* y, lamentablemente, esa empresa había sido completamente negligente, al parecer, en la seguridad de sus datos.
De hecho, su ex director ejecutivo está en problemas con las autoridades por cargos que podrían resultar en una sentencia de prisión, porque simplemente tenían toda esta información dinamita que realmente les debían proteger a sus pacientes, y no la tenían.
Lo pusieron en un servidor en la nube con una contraseña predeterminada, aparentemente, donde el ladrón lo encontró por casualidad.
Pero es la naturaleza de cómo se desarrolló la brecha lo que fue realmente horrible.
Chantajeó a la empresa... Creo que dijo: "Quiero 450,000 € o desvelaré todos los datos".
Y, por supuesto, la compañía se había mantenido en silencio al respecto; es por eso que los reguladores también decidieron perseguir a la compañía.
Se habían mantenido en silencio al respecto, con la esperanza de que nadie se enterara, y aquí viene este tipo diciendo: "Páguenos el dinero, o de lo contrario".
Bueno, no le iban a pagar.
No tenía sentido: ya tenía la fecha, y ya estaba haciendo cosas malas con ella.
Y así, como usted dice, los ladrones decidieron: "Bueno, si no puedo obtener € 450,000 de la empresa, ¿por qué no trato de contactar a todas y cada una de las personas que recibieron psicoterapia por € 200 cada una?"
Según el conocido periodista cibernético Brian Krebs, su nota de extorsión decía: “Tienes 24 horas para pagarme 200 €. Entonces te doy 48 horas para pagar 500€. Y si no he tenido noticias tuyas después de 72 horas, les contaré a tus amigos y familiares, y a cualquiera que quiera saber, las cosas que dijiste”.
Porque esos datos incluían transcripciones, Doug.
¿Por qué demonios estaban almacenando esas cosas por defecto en primer lugar?
Eso nunca lo entenderé.
Como dices, huyó del país y los finlandeses lo arrestaron "en ausencia"; que les permitió emitir una orden de captura internacional.
De todos modos, ahora se enfrenta a la música en Francia, donde, por supuesto, los franceses buscan extraditarlo a Finlandia, y los finlandeses buscan llevarlo a los tribunales.
Aparentemente tiene forma [equivalente estadounidense: anteriores] para esto. doug
Ha sido condenado por delitos cibernéticos antes, pero en ese entonces era menor de edad.
Ahora tiene 25 años, creo; en ese entonces tenía 17 años, así que tuvo una segunda oportunidad.
Recibió una sentencia suspendida y una pequeña multa.
Pero si estas acusaciones son correctas, creo que muchos de nosotros sospechamos que esta vez no se librará tan a la ligera si es declarado culpable.
DOUG. Así que este es un buen recordatorio de que usted puede ser, si es como esta empresa, tanto la víctima *como* el culpable.
Y otro recordatorio más de que tienes que tener un plan en marcha.
Entonces, tenemos algunos consejos al final del artículo, comenzando con: Ensaya lo que harás si sufres una infracción tú mismo.
¡Tienes que tener un plan!
PATO. Absolutamente.
No puedes inventarlo sobre la marcha, porque simplemente no habrá tiempo.
DOUG. Y también, si eres una persona afectada por algo como esto: Considere la posibilidad de presentar un informe, ya que ayuda con la investigación.
PATO. De hecho lo hace.
Tengo entendido que, en este caso, muchas personas que recibieron estas demandas de extorsión *fueron* a las autoridades y dijeron: “Esto salió de la nada. ¡Esto es como ser asaltado en la calle! ¿Qué vas a hacer al respecto?"
Las autoridades dijeron: “Genial, recopilemos los informes”, y eso significa que pueden construir un mejor caso y hacer un caso más sólido para algo como la extradición.
DOUG. Muy bien, muy bien.
Completaremos nuestro programa con: "Otra semana, otro administrador de contraseñas en el banquillo".
Esta vez, es KeePass.
Pero este alboroto en particular no es tan sencillo, Paul:
"Vulnerabilidad" de robo de contraseñas reportada en KeePass: ¿error o característica?
PATO. De hecho, Doug, creo que podrías decir que es muy sencillo... e inmensamente complicado al mismo tiempo. [RISAS]
DOUG. [RISAS] Bien, hablemos de cómo funciona esto realmente.
La función en sí es una especie de función de automatización, un tipo de secuencia de comandos...
PATO. “Disparador” es el término que hay que buscar, así es como lo llaman.
Entonces, por ejemplo, cuando guarde el archivo de la base de datos [KeePass], por ejemplo (tal vez actualizó una contraseña o generó una nueva cuenta y presionó el botón Guardar), ¿no sería bueno si pudiera llamar? ¿Un script personalizado propio que sincronice esos datos con alguna copia de seguridad en la nube?
En lugar de intentar escribir código en KeePass para manejar todos los sistemas de carga en la nube posibles del mundo, ¿por qué no proporcionar un mecanismo en el que las personas puedan personalizarlo si lo desean?
Exactamente lo mismo cuando intentas usar una contraseña... dices: "Quiero copiar esa contraseña y usarla".
¿No sería bueno si pudiera llamar a un script que obtiene una copia de la contraseña de texto sin formato, de modo que pueda usarla para iniciar sesión en cuentas que no son tan simples como poner los datos en un formulario web que está en tu pantalla?
Eso podría ser algo así como su cuenta de GitHub, o su cuenta de Integración Continua, o lo que sea.
Entonces, estas cosas se denominan "disparadores" porque están diseñadas para activarse cuando el producto hace ciertas cosas.
Y algunas de esas cosas, inevitablemente, porque es un administrador de contraseñas, tienen que ver con el manejo de sus contraseñas.
Los detractores sienten que, "Oh, bueno, esos disparadores, son demasiado fáciles de configurar, y agregar un disparador no está protegido por una contraseña de protección contra manipulaciones".
Debe ingresar una contraseña maestra para obtener acceso a sus contraseñas, pero no tiene que ingresar la contraseña maestra para obtener acceso al archivo de configuración para obtener acceso a las contraseñas.
De ahí, creo, de donde vienen los detractores.
Y otras personas están diciendo: “¿Sabes qué? Tienen que obtener acceso al archivo de configuración. ¡Si tienen eso, ya estás en serios problemas!”
DOUG. "La gente" incluye a KeePass, quien dice: "Este programa no está configurado para defenderse de alguien [RISAS] que está sentado en su silla cuando ya ha iniciado sesión en su máquina y en la aplicación".
PATO. Ciertamente.
Y creo que la verdad probablemente esté en algún punto intermedio.
Puedo ver el argumento de por qué, si va a tener las contraseñas protegidas con la contraseña maestra... ¿por qué no protege también el archivo de configuración?
Pero también estoy de acuerdo con la gente que dice: “¿Sabes qué? Si han iniciado sesión en tu cuenta, están en tu computadora y ya eres tú, ya ocupaste el segundo lugar en la carrera”.
¡Así que no hagas eso!
DOUG. [RISAS] Bien, si nos alejamos un poco de esta historia...
… Richard, lector de Naked Security, pregunta:
¿Es un administrador de contraseñas, sin importar cuál, un único punto de falla? Por diseño, es un objetivo de alto valor para un hacker. Y la presencia de cualquier vulnerabilidad permite a un atacante robar todas las contraseñas del sistema, independientemente de la fuerza teórica de esas contraseñas.
Creo que esa es una pregunta que mucha gente se está haciendo en este momento.
PATO. En cierto modo, Doug, esa es una especie de pregunta sin respuesta.
Un poco como este "disparador" en el archivo de configuración en KeePass.
¿Es un error, o es una característica, o tenemos que aceptar que es un poco de ambos?
Creo que, como dijo otro comentarista en ese mismo artículo, hay un problema al decir: “Un administrador de contraseñas es un único punto de falla, así que no voy a usar uno. Lo que haré es pensar en *una* contraseña muy, muy complicada y la usaré para todos mis sitios”.
Que es lo que mucha gente hace si no está usando un administrador de contraseñas... y en lugar de ser un *potencial* único punto de falla, eso crea algo que es exactamente, absolutamente *y ya* un único punto de falla.
Por lo tanto, un administrador de contraseñas es sin duda el menor de dos males.
Y creo que hay mucho de verdad en eso.
DOUG. Sí, diría que creo que *puede* ser un único punto de falla, dependiendo de los tipos de cuentas que mantenga.
Pero para muchos servicios, no es ni debería ser un único punto de falla *total*.
Por ejemplo, si me roban la contraseña de mi banco y alguien ingresa a mi cuenta bancaria, mi banco verá que está ingresando desde el otro lado del mundo y dirá: “¡Vaya! ¡Espera un segundo! Esto se ve raro.
Y me harán una pregunta de seguridad, o me enviarán por correo electrónico un código secundario que debo ingresar, incluso si no estoy configurado para 2FA.
La mayoría de mis cuentas importantes... No me preocupo tanto por esas credenciales, porque habría un segundo factor automático que tendría que pasar porque el inicio de sesión parecería sospechoso.
Y espero que la tecnología sea tan fácil de implementar que cualquier sitio que guarde algún tipo de datos tenga eso integrado: "¿Por qué esta persona se conecta desde Rumania en medio de la noche, cuando normalmente está en Boston?"
Muchos de esos dispositivos de seguridad están en su lugar para cosas muy importantes que puede mantener en línea, por lo que espero que no sea un punto único de falla en ese sentido.
PATO. Ese es un gran punto, Doug, y creo que ilustra que hay, si quieres, una pregunta candente detrás de la pregunta, que es: "¿Por qué necesitamos tantas contraseñas en primer lugar?"
Y tal vez una forma de dirigirse hacia un futuro sin contraseña es simplemente permitir que las personas usen sitios web donde pueden elegir *no* tener la (comillas en el aire) "gran comodidad" de tener que crear una cuenta en primer lugar.
DOUG. [RISA GLUM] Como discutimos, me afectó la violación de LastPass, miré mi lista gigante de contraseñas y dije: "¡Oh, Dios mío, tengo que ir a cambiar todas estas contraseñas!"
Resultó que tuve que *cambiar* la mitad de esas contraseñas y, lo que es peor, tuve que *cancelar* la otra mitad de estas cuentas, porque tenía tantas cuentas ahí…
…solo por lo que dijiste; "Tengo que crear una cuenta solo para acceder a algo en este sitio".
Y no todos son simplemente hacer clic y cancelar.
Algunos, tienes que llamar.
Algunos, tienes que hablar con alguien a través del chat en vivo.
Fue mucho más arduo que simplemente cambiar un montón de contraseñas.
Pero insto a las personas, ya sea que esté usando un administrador de contraseñas o no, a que eche un vistazo a la gran cantidad de cuentas que tiene y elimine las que ya no usa.
PATO. Sí.
En tres palabras, “Menos es más”.
DOUG. ¡Por supuesto!
Muy bien, muchas gracias, Richard, por enviar eso.
Si tiene una historia interesante, un comentario o una pregunta que le gustaría enviar, nos encantaría leerlo en el podcast.
Puede enviar un correo electrónico a tips@sophos.com, puede comentar cualquiera de nuestros artículos o puede contactarnos en las redes sociales: @NakedSecurity.
Ese es nuestro programa de hoy; muchas gracias por escuchar
Para Paul Ducklin, soy Doug Aamoth, les recuerdo hasta la próxima para...
AMBAS COSAS. ¡Mantente seguro!
[MÓDEM MUSICAL]
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
- Fuente: https://nakedsecurity.sophos.com/2023/02/09/s3-ep121-can-you-get-hacked-and-then-prosecuted-for-it-audio-text/
