¿No hay reproductor de audio debajo? Escuchar directamente en Soundcloud.

DOUG.  Grietas en el administrador de contraseñas, errores de inicio de sesión y la reina Isabel I contra María, reina de Escocia... ¡por supuesto!

Todo eso, y más, en el podcast de Naked Security.

[MÓDEM MUSICAL]

Bienvenidos al podcast, todos.

Soy Doug Aamoth; él es Paul Ducklin.

Pablo, ¿cómo estás?

PATO.  ¡Wow!

La artimaña de la tecnología de la información del siglo XVI se encuentra con el podcast de Naked Security, Douglas.

No puedo esperar!

DOUG.  Obviamente, sí... llegaremos a eso en breve.

Pero primero, como siempre, esta semana en la historia de la tecnología, el 28 de mayo de 1987, el proveedor de servicios en línea CompuServe lanzó algo llamado Graphics Interchange Format, o GIF [HARD G].

Fue desarrollado por el difunto Steve Wilhite, un ingeniero de CompuServe (quien, por cierto, juraba que se pronunciaba "jif") como un medio para admitir imágenes en color en el ancho de banda limitado y las capacidades de almacenamiento de las primeras redes informáticas.

La versión inicial, GIF 87a, admitía un máximo de 256 colores; rápidamente ganó popularidad debido a su capacidad para mostrar animaciones simples y su soporte generalizado en diferentes sistemas informáticos.

Gracias, Sr. Wilhite.

PATO.  ¿Y qué nos ha dejado, Douglas?

Animaciones web y controversia sobre si la palabra se pronuncia “graphics” [HARD G] o “giraffics” [SOFT G].

DOUG.  Exactamente. [RISAS]

PATO.  No puedo dejar de llamarlo "giff" [HARD G].

DOUG.  ¡Mismo!

Afirmemos eso y pasemos a nuestra emocionante historia...

…sobre la reina Isabel I, María, reina de Escocia, y un hombre jugando ambos lados entre los ladrones de ransomware y su empleador, Paul.

Cuentos de ransomware: el ataque MitM que realmente tuvo un hombre en el medio

PATO.  [RISAS] Empecemos por el final de la historia.

Básicamente, se trataba de un ataque de ransomware contra una empresa de tecnología en Oxfordshire, Inglaterra.

(Esta no... era una empresa en Oxford, 15 km río arriba de Abingdon-on-Thames, donde tiene su sede Sophos).

Después de ser atacados por ransomware, como se puede imaginar, se vieron afectados por una demanda de pago de Bitcoin para recuperar sus datos.

Y, como esa historia, tuvimos una hace un par de semanas, uno de su propio equipo defensivo, que se suponía que estaba ayudando a lidiar con esto, descubrió: "Voy a ejecutar un MiTM", un ataque Man-in-the-Middle.

Lo sé, para evitar el lenguaje de género y reflejar el hecho de que no siempre es una persona (a menudo es una computadora en el medio) en estos días...

... en Naked Security, ahora escribo "Manipulator-in-the-Middle".

Pero este era literalmente un hombre en el medio.

En pocas palabras, Doug, se las arregló para comenzar a enviar correos electrónicos a su empleador desde su casa, utilizando una especie de cuenta de correo electrónico tipo typosquat que era como la dirección de correo electrónico del ladrón.

Él secuestró el hilo y cambió la dirección de Bitcoin en los rastros históricos de correo electrónico, porque tenía acceso a las cuentas de correo electrónico de los altos ejecutivos...

… y básicamente comenzó a negociar como un hombre en el medio.

Entonces, imagina que ahora está negociando individualmente con el ladrón, y luego le está pasando esa negociación a su empleador.

No sabemos si esperaba irse con toda la recompensa y luego simplemente decirle a su empleador: "Oye, adivina qué, los ladrones nos engañaron", o si quería negociar con los ladrones de su lado, y su empleador en el otro extremo.

Porque sabía todas las cosas correctas e incorrectas que decir para aumentar el miedo y el terror dentro de la empresa.

Entonces, su objetivo era básicamente secuestrar el pago del ransomware.

Bueno, Doug, todo salió un poco mal porque, desafortunadamente para él y afortunadamente para su empleador y para la policía, la compañía decidió no pagar.

DOUG.  [RISAS] ¡Hmmmm!

PATO.  Así que no había Bitcoin para robar y luego cortar y correr.

Además, parece que no ocultó muy bien sus rastros, y su acceso ilegal a los registros de correo electrónico luego salió a la luz.

Obviamente sabía que la policía se estaba acercando a él, porque trató de borrar los datos falsos de sus propias computadoras y teléfonos en casa.

Pero fueron incautados y los datos fueron recuperados.

De alguna manera, el caso se prolongó durante cinco años y, finalmente, justo cuando estaba a punto de ir a juicio, obviamente decidió que realmente no tenía una pierna en la que apoyarse y se declaró culpable.

Ahí lo tienes, Doug.

¡Un ataque literal de hombre en el medio!

DOUG.  OK, así que todo está muy bien en 2023...

…pero llévanos de vuelta a los años 1580, Pablo.

¿Qué pasa con María, Reina de Escocia y la Reina Isabel I?

PATO.  Bueno, para ser honesto, pensé que era una excelente manera de explicar un ataque de hombre en el medio retrocediendo todos esos años.

Porque, como es bien sabido, la reina Isabel y su prima María, reina de Escocia, eran enemigas políticas y religiosas.

Isabel era la reina de Inglaterra; María era pretendiente al trono.

Entonces, Mary fue efectivamente detenida bajo arresto domiciliario.

Mary vivía con cierto lujo, pero confinada en un castillo, y en realidad estaba conspirando contra su prima, pero no pudieron probarlo.

Y Mary enviaba y recibía mensajes metidos en los tapones de los barriles de cerveza entregados en el castillo.

Aparentemente, en este caso, el hombre en el medio era un proveedor de cerveza cumplidor que eliminaría los mensajes antes de que Mary los recibiera, para que pudieran ser copiados.

E insertaría mensajes de reemplazo, encriptados con el cifrado de Mary, con cambios sutiles que, en términos generales, eventualmente persuadieron a Mary a poner por escrito más de lo que probablemente debería.

Por lo que no solo entregó los nombres de otros conspiradores, también indicó que aprobaba el complot para asesinar a la reina Isabel.

Eran tiempos más duros entonces... e Inglaterra ciertamente tenía la pena de muerte en esos días, y Mary fue juzgada y ejecutada.

Los 10 mejores textos cifrados descifrados de la historia

DOUG.  De acuerdo, para cualquiera que escuche, el discurso de ascensor de este podcast es: "Noticias y consejos sobre ciberseguridad, y un poco de historia".

Volvamos a nuestro hombre en el medio en el día actual.

Nosotros hablamos acerca de otra amenaza interna así no hace mucho tiempo.

Entonces, sería interesante ver si esto es un patrón o si es solo una coincidencia.

Pero hablamos sobre algunas cosas que puede hacer para protegerse contra este tipo de ataques, así que repasemos eso rápidamente nuevamente.

Empezando con: Divide y vencerás, que básicamente significa: "No le des a una sola persona de la empresa acceso sin restricciones a todo", Paul.

PATO.  Sí.

DOUG.  Y luego tenemos: Mantener registros inmutables, que parecía que sucedió en este caso, ¿verdad?

PATO.  Sí.

Parece que un elemento clave de la evidencia en este caso fue el hecho de que había estado investigando los correos electrónicos de los altos ejecutivos y cambiándolos, y no pudo ocultarlo.

Así que imagina, incluso sin la otra evidencia, el hecho de que estaba jugando con correos electrónicos que se relacionaban específicamente con negociaciones de ransomware y direcciones de Bitcoin sería súper sospechoso.

DOUG.  Bien, finalmente: Mide siempre, nunca asumas.

PATO.  ¡Ciertamente!

DOUG.  Los buenos finalmente ganaron... tomó cinco años, pero lo logramos.

Pasemos a nuestra siguiente historia.

Empresa de seguridad web encuentra un error de inicio de sesión en un conjunto de herramientas de creación de aplicaciones.

El error se soluciona de forma rápida y transparente, así que está bien... pero hay un poco más a la historia, por supuesto, Pablo.

Seguridad seria: la verificación es vital: examinar un error de inicio de sesión de OAUTH

PATO.  Sí.

Esta es una empresa de análisis de seguridad de codificación web (espero haber elegido la terminología correcta allí) llamada SALT, y encontraron una vulnerabilidad de autenticación en un conjunto de herramientas de creación de aplicaciones llamado Expo.

Y, bendiciones para sus corazones, Expo apoya una cosa llamada OAUTH, el Autorización abierta .

Ese es el tipo de sistema que se utiliza cuando se visita un sitio web que ha decidido: “Sabes qué, no queremos la molestia de tratar de aprender a proteger nuestras contraseñas nosotros mismos. Lo que vamos a hacer es decir, 'Inicie sesión con Google, inicie sesión con Facebook'”, algo así.

Y la idea es que, en términos generales, se comunique con Facebook, o Google, o cualquiera que sea el servicio principal y diga: "Oye, quiero darte example.com permiso para hacer X.”

Entonces, Facebook, o Google, o lo que sea, lo autentica y luego dice: “OK, aquí hay un código mágico que puede dar al otro extremo que dice: 'Te hemos verificado; te has autenticado con nosotros, y este es tu token de autenticación”.

Luego, el otro extremo puede verificar de forma independiente con Facebook, Google o lo que sea para asegurarse de que ese token se haya emitido en su nombre.

Entonces, lo que eso significa es que nunca necesita entregar ninguna contraseña para el sitio ... está, si lo desea, cooptando a Facebook o Google para que realicen la parte de autenticación real por usted.

Es una gran idea si tiene un sitio web boutique y piensa: "No voy a tejer mi propia criptografía".

Entonces, esto no es un error en OAUTH.

Es solo un descuido; algo que se olvidó en la implementación de Expo del proceso OAUTH.

Y, en términos generales, Doug, es así.

El código Expo crea una URL gigante que incluye todos los parámetros que se necesitan para autenticarse con Facebook y luego decidir dónde se debe enviar ese token de acceso mágico final.

Por lo tanto, en teoría, si construyó su propia URL o pudo modificar la URL, podría cambiar el lugar donde finalmente se envió este token de autenticación mágica.

Pero no podría engañar al usuario, porque aparece un cuadro de diálogo que dice: "La aplicación en URL-here te está pidiendo que inicies sesión en tu cuenta de Facebook. ¿Confías plenamente en esto y quieres dejar que lo haga? ¿Sí o no?"

Sin embargo, cuando llegó el momento de recibir el código de autorización de Facebook, o Google, o lo que sea, y pasarlo a esta "URL de retorno", el código Expo no comprobaría que realmente había hecho clic. Yes en el diálogo de aprobación.

Si vio activamente el cuadro de diálogo e hizo clic en No, entonces evitaría que suceda el ataque.

Pero, esencialmente, este "fallo abierto".

Si nunca vio el diálogo, entonces ni siquiera sabría que había algo para hacer clic y simplemente no hizo nada, y luego los atacantes simplemente activaron la próxima visita de URL por sí mismos con más JavaScript...

…entonces el sistema funcionaría.

Y la razón por la que funcionó es que la "URL de retorno" mágica, el lugar donde se enviaría el código de autorización supersecreto, se configuró en una cookie web para que Expo lo use más tarde *antes de hacer clic Yes en el diálogo*.

Más tarde, la existencia de esa cookie de "URL de retorno" se tomó esencialmente, si lo desea, como prueba de que debe haber visto el cuadro de diálogo y debe haber decidido continuar.

Mientras que, de hecho, ese no fue el caso.

Así que fue un gran desliz entre la copa y el labio, Douglas.

DOUG.  Bien, tenemos algunos consejos, comenzando con: Cuando se trataba de informar y divulgar este error, este era un caso de libro de texto.

Así es casi exactamente como deberías hacerlo, Paul.

Todo funcionó como debería, por lo que este es un gran ejemplo de cómo hacerlo de la mejor manera posible.

PATO.  Y esa es una de las razones principales por las que quería escribirlo en Naked Security.

SALT, las personas que encontraron el error...

..ellos lo encontraron; lo divulgaron responsablemente; trabajaron con Expo, que lo arregló, literalmente, en cuestión de horas.

Entonces, a pesar de que fue un error, a pesar de que fue un error de codificación, llevó a SALT a decir: "Sabes qué, fue un placer trabajar con la gente de la Expo".

Luego, SALT comenzó a obtener un CVE, y en lugar de decir: "Oye, el error se solucionó ahora, así que dos días después podemos hacer un gran revuelo de relaciones públicas al respecto", sin embargo, establecieron una fecha tres meses antes cuando realmente escribirían sus hallazgos y redactar su muy educativo informe.

En lugar de apresurarse con fines de relaciones públicas inmediatos, en caso de que fueran detectados en el último minuto, no solo informaron esto de manera responsable para que pudiera solucionarse antes de que los delincuentes lo encontraran (y no hay evidencia de que alguien haya abusado de esta vulnerabilidad), también luego dio un poco de margen para que Expo saliera y se comunicara con sus clientes.

DOUG.  Y luego, por supuesto, hablamos un poco sobre esto: Asegúrese de que sus comprobaciones de autenticación no se hayan cerrado.

Asegúrese de que no siga funcionando si alguien lo ignora o lo cancela.

Pero el problema más grande aquí es: Nunca asuma que su propio código del lado del cliente controlará el proceso de verificación.

PATO.  Si siguió el proceso exacto del código JavaScript proporcionado por Expo para guiarlo a través de este proceso OAUTH, habría estado bien.

Pero si evitó su código y en realidad simplemente activó los enlaces con su propio JavaScript, incluyendo eludir o cancelar la ventana emergente, entonces ganó.

Pasar por alto el código de su cliente es lo primero en lo que pensará un atacante.

DOUG.  Muy bien, por último pero no menos importante: Cierra la sesión de las cuentas web cuando no las estés usando activamente.

Ese es un buen consejo en general.

PATO.  Lo decimos todo el tiempo en el podcast Naked Security, y tenemos para años.

3 sencillos pasos para la seguridad en línea

Es un consejo impopular, porque es bastante inconveniente, de la misma manera que decirle a la gente: "Oye, ¿por qué no configuras tu navegador para borrar todas las cookies al salir?"

Si lo piensas bien, en este caso particular… digamos que el inicio de sesión se estaba realizando a través de tu cuenta de Facebook; OAUTH a través de Facebook.

Si se desconectó de Facebook, entonces no importa qué traición de JavaScript haya intentado un atacante (matar la ventana emergente de la Expo y todo eso), el proceso de autenticación con Facebook no tendría éxito porque Facebook diría: "Oye, la cuenta de esta persona". pidiéndome que los autentique. Actualmente no están conectados”.

Por lo tanto, siempre e inevitablemente verá aparecer el inicio de sesión de Facebook en ese punto: "Necesita iniciar sesión ahora".

Y eso delataría el subterfugio inmediatamente.

DOUG.  Ok muy bien.

Y nuestra última historia del día: no se asuste, pero aparentemente hay una manera de descifrar la contraseña maestra para el administrador de contraseñas de código abierto KeePass.

Pero, de nuevo, no se asuste, porque es un mucho más complicado de lo que parece, Pablo.

Realmente tienes que tener el control de la máquina de alguien.

Seguridad seria: el "crackeo de la contraseña maestra" de KeePass y lo que podemos aprender de él

PATO.  Tú lo haces.

Si desea rastrear esto, es CVE-2023-32784.

Es un error fascinante, y escribí una especie de Obra Maestra artículo de estilo en Naked Security al respecto, titulado: Ese 'crackeo de contraseña maestra' de KeePass y lo que podemos aprender de él.

Así que no estropearé ese artículo, que trata sobre la asignación de memoria tipo C, la asignación de memoria tipo lenguaje de secuencias de comandos y, finalmente, las cadenas administradas por C# o .NET... la asignación de memoria administrada por el sistema.

Me limitaré a describir lo que descubrió el investigador en este caso.

Lo que hicieron fue... buscaron en el código de KeePass y en los volcados de memoria de KeePass, en busca de pruebas de lo fácil que podría ser encontrar la contraseña maestra en la memoria, aunque sea temporalmente.

¿Qué pasa si está ahí minutos, horas o días después?

¿Qué pasa si la contraseña maestra todavía está por ahí, tal vez en su archivo de intercambio en el disco, incluso después de haber reiniciado su computadora?

Así que configuré KeePass y me asigné una contraseña de 16 caracteres en mayúsculas para que fuera fácil de reconocer si la encontraba en la memoria.

Y he aquí que en ningún momento encontré mi contraseña maestra en la memoria: no como una cadena ASCII; no como una cadena de Windows widechar (UTF-16)).

¡Excelente!

Pero lo que notó este investigador es que cuando ingresa su contraseña en KeePass, aparece... Lo llamaré "el carácter blob de Unicode", solo para mostrarle que sí, presionó una tecla y, por lo tanto, para mostrarle cuántos caracteres ha escrito.

Entonces, a medida que escribe su contraseña, verá la cadena blob [●], blob-blob [●●], blob-blob-blob [●●●] y, en mi caso, todo hasta 16 blobs.

Bueno, esas cadenas de blob no parecen ser un riesgo para la seguridad, por lo que tal vez solo se las dejó en el tiempo de ejecución de .NET para administrarlas como "cadenas administradas", donde podrían permanecer en la memoria después...

…y no limpiarse porque, “Oye, son solo manchas”.

Resulta que si haces un volcado de memoria de KeePass, lo que te da la friolera de 250 MB de cosas, y buscas cadenas como blob-blob, blob-blob-blob, etc. (cualquier cantidad de blobs), hay un trozo de volcado de memoria donde verás dos blobs, luego tres blobs, luego cuatro blobs, luego cinco blobs... y en mi caso, hasta 16 blobs.

Y luego obtendrás esta colección aleatoria de "caracteres blob que suceden por error", si lo deseas.

En otras palabras, solo buscar esas cadenas de blob, aunque no revelen su contraseña real, filtrará la longitud de su contraseña.

Sin embargo, se vuelve aún más interesante, porque lo que este investigador se preguntó es: "¿Qué sucede si los datos cercanos a esas cadenas de blob en la memoria pueden estar vinculados de alguna manera a los caracteres individuales que ingresa en la contraseña?"

Entonces, ¿qué sucede si revisa el archivo de volcado de memoria y, en lugar de solo buscar dos blobs, tres blobs / cuatro blobs, más ...

…buscas una cadena de blobs seguidos de un carácter que crees que está en la contraseña?

Entonces, en mi caso, solo estaba buscando los caracteres de la A a la Z, porque sabía que eso era lo que estaba en la contraseña.

Estoy buscando cualquier cadena de blobs, seguida de un carácter ASCII.

Adivina lo que pasó, Doug?

Obtengo dos blobs seguidos del tercer carácter de mi contraseña; tres blobs seguidos del cuarto carácter de mi contraseña; todo el camino hasta 15 blobs seguidos inmediatamente por el carácter 16 en mi contraseña.

DOUG.  ¡Sí, es una imagen salvaje en este artículo!

Lo estaba siguiendo... se estaba volviendo un poco técnico, y de repente solo veo, "¡Vaya! ¡Eso parece una contraseña!”

PATO.  Es básicamente como si los caracteres individuales de su contraseña estuvieran dispersos generosamente en la memoria, pero los que representan los caracteres ASCII que en realidad formaban parte de su contraseña cuando la escribió...

…es como si tuvieran un dado luminiscente adherido a ellos.

Por lo tanto, estas cadenas de blobs actúan sin darse cuenta como un mecanismo de etiquetado para marcar los caracteres de su contraseña.

Y, en realidad, la moraleja de la historia es que las cosas pueden filtrarse en la memoria de maneras que simplemente nunca esperó, y que incluso un revisor de código bien informado podría no darse cuenta.

Es una lectura fascinante y un gran recordatorio de que escribir código seguro puede ser mucho más difícil de lo que cree.

Y lo que es más importante, revisar, garantizar la calidad y probar el código seguro puede ser aún más difícil...

…porque tienes que tener ojos en la parte delantera, trasera y a los lados de la cabeza, y realmente tienes que pensar como un atacante y tratar de buscar secretos filtrados absolutamente en todos los lugares que puedas.

DOUG.  Bien, échale un vistazo, está en makedsecurity.sophos.com.

Y, a medida que el sol comienza a ponerse en nuestro programa, es hora de escuchar a uno de nuestros lectores.

En el podcast anterior (este es uno de mis comentarios favoritos, Paul), el oyente de Naked Security, Chang, comenta:

Allá. Lo he hecho. Después de casi dos años de escuchar atracones, terminé de escuchar todos los episodios del podcast Naked Security. Estoy todo atrapado.

Lo disfruté desde el principio, comenzando con el Chet Chat de larga duración; luego a la tripulación del Reino Unido; "¡Oh, no! Es Kim” fue el siguiente; luego finalmente llegué a "Esta semana en la historia de la tecnología" del presente.

¡Qué viaje!

¡Gracias, Chang!

No puedo creer que te hayas emborrachado con todos los episodios, pero todos (espero no estar hablando fuera de lugar) lo apreciamos mucho.

PATO.  ¡Mucho por cierto, Doug!

Es bueno saber no solo que las personas están escuchando, sino también que encuentran útiles los podcasts, y que los está ayudando a aprender más sobre ciberseguridad y a mejorar su juego, aunque sea solo un poco.

Porque creo, como he dicho muchas veces antes, si todos mejoramos un poco nuestro juego de seguridad cibernética, entonces hacemos mucho más para mantener a raya a los delincuentes que si una o dos empresas, una o dos organizaciones, uno o dos personas se esforzaron mucho, pero el resto nos quedamos atrás.

DOUG.  ¡Exactamente!

Bueno, muchas gracias de nuevo, Chang, por enviar eso.

Nosotros realmente lo apreciamos.

Y 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, que...

AMBAS COSAS.  ¡Mantente seguro!

[MÓDEM MUSICAL]