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

DOUG.  Actualizaciones de Firefox, otro Error con un nombre impresionante, y la SEC exige la divulgación.

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.

Paul, espero que estés orgulloso de mí... Sé que eres un entusiasta del ciclismo.

Ayer monté en bicicleta durante 10 millas americanas, que creo que son aproximadamente 16 km, todo mientras tiraba de un niño pequeño pero no poco pesado detrás de la bicicleta en un carruaje de dos ruedas.

Y todavía estoy vivo para contarlo.

¿Es un largo camino andar en bicicleta, Paul?

PATO.  [RISAS] Depende de cuán lejos realmente necesitabas llegar.

Como si en realidad fueran 1200 metros los que tuvieras que recorrer y te perdieras… [RISAS]

Mi entusiasmo por el ciclismo es muy alto, pero eso no significa que deliberadamente vaya más lejos de lo necesario, porque es mi forma principal de desplazarme.

Pero 10 millas está bien.

¿Sabías que las millas americanas y las británicas son, de hecho, idénticas?

DOUG.  ¡Es bueno saber eso!

PATO.  Y lo ha sido desde 1959, cuando un grupo de países, incluidos, creo, Canadá, Sudáfrica, Australia, los Estados Unidos y el Reino Unido se unieron y acordaron estandarizar en una "pulgada internacional".

Creo que la pulgada imperial se hizo muy, muy ligeramente más pequeña y la pulgada americana se hizo muy, muy ligeramente más larga, con el resultado de que la pulgada (y por lo tanto la yarda, el pie y la milla)...

…todos están definidos en términos del metro.

Una pulgada es exactamente 25.4 mm.

Tres cifras significativas es todo lo que necesitas.

DOUG.  ¡Fascinante!

Bueno, hablando de fascinante, es hora de que nuestro Esta semana en la historia de la tecnología segmento.

Esta semana, el 01 de agosto de 1981, Music Television, también conocida como MTV, se lanzó como parte de los paquetes de televisión por cable y satélite estadounidenses y presentó al público videos musicales.

El primero tocó [CANTA, DE HECHO BASTANTE BIEN] “Video Killed the Radio Star” de The Buggles.

Adecuado en ese momento, aunque irónico hoy en día, ya que MTV rara vez reproduce videos musicales y no reproduce videos musicales nuevos en absoluto, Paul.

PATO.  Sí, es irónico, ¿no es así? Que la televisión por cable (en otras palabras, donde tenías cables debajo del suelo hasta tu casa) mató a la estrella de la radio (o la tecnología inalámbrica), y ahora parece que la televisión por cable, MTV... eso se extinguió porque todo el mundo tiene redes móviles que funcionan de forma inalámbrica.

Lo que va, vuelve, Douglas.

DOUG.  Muy bien, bueno, hablemos de estas actualizaciones de Firefox.

Recibimos una dosis doble de actualizaciones de Firefox este mes, porque tienen un ciclo de 28 días:

Firefox corrige una serie de fallas en el primero de los dos lanzamientos de este mes

No hay días cero en esta primera ronda, pero sí algunos momentos de aprendizaje.

Hemos enumerado tal vez la mitad de estos en su artículo, y uno que realmente me llamó la atención fue: Omisión de solicitud de permisos potenciales a través de clickjacking.

PATO.  Sí, el viejo clickjacking de nuevo.

Me gusta ese término porque describe más o menos lo que es.

Hace clic en algún lugar, pensando que está haciendo clic en un botón o en un enlace inocente, pero sin darse cuenta está autorizando que suceda algo que no es obvio a partir de lo que muestra la pantalla debajo del cursor del mouse.

El problema aquí parece ser que, en algunas circunstancias, cuando un cuadro de diálogo de permisos estaba a punto de aparecer desde Firefox, por ejemplo, dice: "¿Estás realmente seguro de que quieres permitir que este sitio web use tu cámara? tener acceso a su ubicación? usar tu micrófono?”…

…todas esas cosas que, sí, quieres que te pregunten.

Aparentemente, si pudiera llevar el navegador a un punto de rendimiento (nuevamente, rendimiento versus seguridad) en el que tuviera dificultades para mantenerse al día, podría retrasar la aparición de la ventana emergente de permisos.

Pero al tener un botón en el lugar donde aparecería la ventana emergente y atraer al usuario para que haga clic en él, podría atraer el clic, pero el clic se enviaría al cuadro de diálogo de permisos que aún no había visto.

Una especie de condición de carrera visual, por así decirlo.

DOUG.  OK, y el otro era: El lienzo fuera de la pantalla podría haber evitado las restricciones de origen cruzado.

Continúa diciendo que una página web podría echar un vistazo a las imágenes que se muestran en otra página desde un sitio diferente.

PATO.  Eso no se supone que suceda, ¿verdad?

DOUG.  ¡No!

PATO.  El término de la jerga para eso es la "política del mismo origen".

Si está ejecutando el sitio web X y me envía un montón de JavaScript que establece una gran cantidad de cookies, entonces todo eso se almacena en el navegador.

Pero solo más JavaScript del sitio X puede leer esos datos.

El hecho de que estés navegando al sitio X en una pestaña y al sitio Y en la otra pestaña no les permite echar un vistazo a lo que está haciendo el otro, y se supone que el navegador debe mantener todas esas cosas separadas.

Eso es obviamente bastante importante.

Y aquí parece que, según tengo entendido, si estuvieras renderizando una página que aún no se mostraba...

…un lienzo fuera de la pantalla, que es donde creas, si lo deseas, una página web virtual y luego, en algún momento futuro, dices: "En este momento, estoy listo para mostrarla", y bingo, la página aparece en una vez.

El problema surge al tratar de asegurarse de que las cosas que está procesando de manera invisible no filtren datos sin darse cuenta, aunque finalmente nunca se muestren al usuario.

Lo detectaron, o se reveló responsablemente, y se parchó.

Y esos dos, creo, se incluyeron en las denominadas vulnerabilidades de nivel "alto".

La mayoría de los otros eran "Moderados", con la excepción del tradicional de Mozilla, "Encontramos muchos errores a través de fuzzing y técnicas automatizadas; no los investigamos para averiguar si podían ser explotados, pero estamos dispuestos a asumir que alguien que se esforzó lo suficiente podría hacerlo”.

Esa es una admisión que a ambos nos gusta mucho, Doug... porque vale la pena eliminar los errores potenciales, incluso si sientes la certeza en tu corazón de que nadie descubrirá cómo explotarlos.

¡Porque en ciberseguridad, vale la pena decir nunca nunca!

DOUG.  Muy bien, estás buscando Firefox 116 o, si tienes una versión extendida, 115.1.

Lo mismo con Thunderbird.

Y pasemos a… ¡oh, hombre!

¡Paul, esto es emocionante!

Tenemos un nuevo BWAIN después de un doble BWAIN la semana pasada: un error con un nombre impresionante.

Este se llama Colisión+Poder:

El rendimiento y la seguridad chocan una vez más en el ataque "Collide+Power"

PATO.  [RISAS] Sí, es intrigante, ¿no es así, que eligieron un nombre que tiene un signo más?

DOUG.  Sí, eso hace que sea difícil de decir.

PATO.  No puede tener un signo más en su nombre de dominio, por lo que el nombre de dominio es collidepower.com.

DOUG.  Muy bien, permítanme leer de los propios investigadores, y cito:

La raíz del problema es que los componentes de la CPU compartida, como el sistema de memoria interna, combinan datos del atacante y datos de cualquier otra aplicación, lo que da como resultado una señal de fuga combinada en el consumo de energía.

Por lo tanto, al conocer sus propios datos, el atacante puede determinar los valores exactos de los datos utilizados en otras aplicaciones.

PATO.  [RISAS] ¡Sí, eso tiene mucho sentido si ya sabes de lo que están hablando!

Para tratar de explicar esto en un lenguaje sencillo (espero haberlo entendido correctamente)...

Esto se reduce a los problemas de rendimiento versus seguridad de los que hemos hablado antes, que incluyen el podcast de la semana pasada con ese Zenbleed error (que es mucho más grave, por cierto):

Zenbleed: cómo la búsqueda del rendimiento de la CPU podría poner en riesgo sus contraseñas

Hay una gran cantidad de datos que se guardan dentro de la CPU ("en caché" es el término técnico para ello) para que la CPU no necesite ir a buscarlos más tarde.

Entonces, hay muchas cosas internas que realmente no puedes administrar; la CPU lo cuida por ti.

Y el corazón de este ataque parece ser algo así...

Lo que hace el atacante es acceder a varias ubicaciones de memoria de tal manera que el almacenamiento de caché interno recuerda esas ubicaciones de memoria, por lo que no tiene que ir y leerlas de la RAM nuevamente si se reutilizan rápidamente.

Entonces, el atacante de alguna manera obtiene estos valores de caché llenos de patrones conocidos de bits, valores de datos conocidos.

Y luego, si la víctima tiene memoria que *ellos* están usando con frecuencia (por ejemplo, los bytes en una clave de descifrado), si la CPU determina repentinamente que es más probable que se reutilice su valor que uno de los valores de los atacantes, saca el valor del atacante de esa ubicación de caché superrápida interna y coloca el nuevo valor, el valor de la víctima, allí.

Y lo que estos investigadores descubrieron (y por muy descabellado que suene el ataque en teoría y lo sea en la práctica, esto es algo asombroso de descubrir)...

La cantidad de bits que son diferentes entre el valor anterior en el caché y el nuevo valor *cambia la cantidad de energía requerida para realizar la operación de actualización del caché*.

Por lo tanto, si puede medir el consumo de energía de la CPU con suficiente precisión, puede hacer inferencias sobre qué valores de datos se escribieron en la memoria caché interna, oculta e invisible dentro de la CPU que la CPU pensó que no era de su incumbencia.

¡Muy intrigante, Doug!

DOUG.  Excepcional.

OK, hay algunas mitigaciones.

Esa sección, comienza: "En primer lugar, no necesita preocuparse", pero también casi todas las CPU se ven afectadas.

PATO.  Sí, eso es interesante, ¿no?

Dice “ante todo” (texto normal) “Usted" (En itálica) "no tiene que preocuparse" (en negrita). [RISAS]

Entonces, básicamente, nadie te va a atacar con esto, pero tal vez los diseñadores de CPU quieran pensar en esto en el futuro si hay alguna forma de evitarlo. [RISAS]

Pensé que era una manera interesante de decirlo.

DOUG.  Bien, entonces la mitigación es básicamente desactivar el hiperprocesamiento.

¿Así es como funciona?

PATO.  Hyperthreading hace que esto sea mucho peor, por lo que puedo ver.

Ya sabemos que el hyperthreading es un problema de seguridad porque ha habido numerosas vulnerabilidades que dependen de él antes.

Es donde una CPU, digamos, con ocho núcleos pretende tener 16 núcleos, pero en realidad no están en partes separadas del chip.

En realidad, son pares de pseudonúcleos que comparten más componentes electrónicos, más transistores, más condensadores, de lo que quizás sea una buena idea por razones de seguridad.

Si está ejecutando OpenBSD, creo que decidieron que el hiperprocesamiento es demasiado difícil de proteger con mitigaciones; también podría apagarlo.

En el momento en que haya recibido los impactos de rendimiento que requieren las mitigaciones, es mejor que no lo tenga.

Entonces creo que desactivar el hiperprocesamiento te inmunizará en gran medida contra este ataque.

Lo segundo que puedes hacer es, como dicen los autores en negrita: No te preocupes. [LA RISA]

DOUG.  ¡Esa es una gran mitigación! [RISAS]

PATO.   Hay una gran parte (tendré que leer esto, Doug)...

Hay una gran parte en la que los propios investigadores descubrieron que para obtener cualquier tipo de información confiable, estaban obteniendo velocidades de datos de entre 10 bits y 100 bits por hora fuera del sistema.

Creo que al menos las CPU de Intel tienen una mitigación que imagino ayudaría contra esto.

Y esto nos lleva de vuelta a los MSR, esos registros específicos del modelo de los que hablamos la semana pasada con Zenbleed, donde había un bit mágico que podías activar que decía: "No hagas las cosas arriesgadas".

Hay una función que puede configurar llamada Filtrado RAPL, y RAPL es la abreviatura de límite de potencia promedio en funcionamiento.

Lo utilizan los programas que quieren ver el rendimiento de una CPU con fines de administración de energía, por lo que no necesita irrumpir en la sala del servidor y colocar un monitor de energía en un cable con una pequeña sonda en la placa base. [RISAS]

De hecho, puede hacer que la CPU le diga cuánta energía está usando.

Intel al menos tiene este modo llamado filtrado RAPL, que introduce deliberadamente fluctuaciones o errores.

Por lo tanto, obtendrá resultados que, en promedio, son precisos, pero donde cada lectura individual será incorrecta.

DOUG.  Volvamos ahora nuestra atención a este nuevo acuerdo de la SEC.

La Comisión de Bolsa y Valores exige límites de divulgación de cuatro días sobre las infracciones de seguridad cibernética:

La SEC exige un límite de divulgación de cuatro días para las infracciones de seguridad cibernética

Pero (A) puedes decidir si un ataque es lo suficientemente grave como para informarlo, y (B) el límite de cuatro días no comienza hasta que decidas que algo es lo suficientemente importante como para informarlo, Paul.

Entonces, ¿un buen primer comienzo, pero quizás no tan agresivo como nos gustaría?

PATO.  Estoy de acuerdo con tu evaluación allí, Doug.

Sonaba genial cuando lo miré por primera vez: "Oye, tienes esta divulgación de cuatro días si tienes una violación de datos o un problema de seguridad cibernética".

Pero luego hubo algo sobre, "Bueno, tiene que ser considerado un problema material", un término legal que significa que en realidad es lo suficientemente importante como para que valga la pena revelarlo en primer lugar.

Y luego llegué a esa parte (y no es un comunicado de prensa muy largo de la SEC) que decía: "Tan pronto como haya decidido que realmente debe informar esto, todavía tiene cuatro días para denunciarlo”.

Ahora, me imagino que, legalmente, no es así como funcionará. Doug

¿Quizás estamos siendo un poco duros en el artículo?

DOUG.  Se enfoca en los ataques de ransomware y dice que hay algunos tipos diferentes, así que hablemos de eso... es importante para determinar si se trata de un ataque material que debe informar.

Entonces, ¿qué tipo de ransomware estamos viendo?

PATO.  Sí, solo para explicar, pensé que era una parte importante de esto.

No quiero señalar con el dedo a la SEC, pero esto es algo que no parece haber salido a la luz en muchos o en ningún país todavía...

…si simplemente sufrir un ataque de ransomware es inevitablemente suficiente para ser una violación de datos importante.

Este documento de la SEC en realidad no menciona la "palabra R" en absoluto.

No hay mención de cosas específicas de ransomware.

Y el ransomware es un problema, ¿no?

En el artículo, quería dejar en claro que la palabra "ransomware", que todavía usamos ampliamente, ya no es la palabra correcta, ¿verdad?

Probablemente deberíamos llamarlo "software de chantaje" o simplemente "ciberextorsión".

Identifico tres tipos principales de ataques de ransomware.

El tipo A es donde los delincuentes no roban sus datos, solo pueden codificar sus datos in situ.

Así que no necesitan subir nada.

Lo codifican todo de manera que pueden proporcionarle la clave de descifrado, pero no verá un solo byte de datos saliendo de su red como una señal reveladora de que algo malo está pasando.

Luego hay un ataque de ransomware tipo B, donde los delincuentes dicen: “Sabes qué, no vamos a arriesgarnos a escribir en todos los archivos y que nos atrapen haciendo eso. Simplemente vamos a robar todos los datos y, en lugar de pagar el dinero para recuperar sus datos, está pagando por nuestro silencio”.

Y luego, por supuesto, está el ataque de ransomware Tipo C, y eso es: "Ambos A y B".

Ahí es donde los delincuentes roban sus datos *y* los codifican y dicen: "Oye, si no es una cosa lo que te va a meter en problemas, es la otra".

Y sería bueno saber dónde creo que la profesión legal llama materialidad (en otras palabras, el significado legal o la relevancia legal para una regulación en particular)...

…dónde entra en juego, en el caso de ataques de ransomware.

DOUG.  Bueno, este es un buen momento para traer a nuestro comentarista de la semana, Adam, sobre esta historia.

Adam da su opinión sobre los distintos tipos de ataques de ransomware.

Entonces, comenzando con el Tipo A, donde es solo un ataque de ransomware directo, donde bloquean los archivos y dejan una nota de rescate para desbloquearlos...

Adán dice:

Si una empresa es atacada por ransomware, no encontró evidencia de exfiltración de datos después de una investigación exhaustiva y recuperó sus datos sin pagar el rescate, entonces me inclinaría a decir: "No [divulgación necesaria]".

PATO.  ¿Has hecho suficiente?

DOUG.  Sí.

PATO.  No lo evitó del todo, pero hizo lo siguiente mejor, por lo que no necesita decírselo a sus inversores...

La ironía es, Doug, que si hubieras hecho eso como empresa, tal vez quisieras decirles a tus inversores: “Oye, ¿adivinen qué? Tuvimos un ataque de ransomware como todos los demás, pero salimos de él sin pagar el dinero, sin comprometernos con los delincuentes y sin perder ningún dato. Entonces, aunque no éramos perfectos, éramos lo siguiente mejor”.

Y en realidad podría tener mucho peso revelar eso voluntariamente, incluso si la ley dice que no tienes que hacerlo.

DOUG.  Y luego, para el Tipo B, el ángulo del chantaje, Adam dice:

Esa es una situación complicada.

Teóricamente, diría, “Sí”.

Pero eso probablemente conducirá a muchas revelaciones y dañará la reputación comercial.

Entonces, si tiene un montón de empresas que salen y dicen: “Mira, nos golpeó el ransomware; no creemos que haya pasado nada malo; pagamos a los ladrones para mantenerlos callados; y estamos confiados en que no los van a soltar”, por así decirlo…

…eso crea una situación delicada, porque podría dañar la reputación de una empresa, pero si no lo hubieran revelado, nadie lo sabría.

PATO.  Y veo que Adam se sintió de la misma manera que tú y yo sobre el asunto de: “Tienes cuatro días, y no más de cuatro días… desde el momento en que crees que deberían comenzar los cuatro días”.

Él retumbó eso también, ¿no?

Él dijo:

Es probable que algunas empresas adopten tácticas para retrasar en gran medida la decisión de si hay un impacto material.

Entonces, no sabemos muy bien cómo se desarrollará esto, y estoy seguro de que la SEC tampoco lo sabe muy bien.

Puede que les tome un par de casos de prueba descubrir cuál es la cantidad correcta de burocracia para asegurarse de que todos aprendamos lo que necesitamos saber, sin obligar a las empresas a revelar cada pequeño problema de TI que ocurra y enterrarnos a todos en un carga de papeleo.

Lo que esencialmente conduce a la fatiga por ruptura, ¿no es así?

Si tienes tantas malas noticias que no son tan importantes que simplemente te invaden...

… de alguna manera, es fácil pasar por alto las cosas realmente importantes que se encuentran entre todos los "¿realmente necesitaba escuchar sobre eso?"

El tiempo lo dirá, Douglas.

DOUG.  ¡Sí, complicado!

Y sé que digo esto todo el tiempo, pero estaremos atentos a esto, porque será fascinante ver cómo se desarrolla.

Entonces, gracias, Adam, por enviar ese comentario.

PATO.  ¡Sí, claro!

DOUG.  Si tiene una historia interesante, un comentario o una pregunta que le gustaría enviar, nos encantaría leer 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]