T3 Ep95: Fuga de Slack, ataque de Github y criptografía poscuántica [Audio + Texto]

Haga clic y arrastre en las ondas sonoras de abajo para saltar a cualquier punto. Tú también puedes escuchar directamente en Soundcloud.

DOUG.  Fugas de holgura, código de GitHub travieso y criptografía poscuántica.

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

[MÓDEM MUSICAL]

Bienvenidos al podcast, todos.

Soy Doug Aamoth.

Conmigo, como siempre, está Paul Ducklin.

Pablo, ¿cómo estás hoy?

---

PATO.  ¡Súper tonto, como siempre, Doug!

---

DOUG.  Estoy super-duper emocionado de llegar a la de esta semana Historia de la tecnología segmento, porque…

... ¡tú estabas allí, hombre!

Esta semana, el 11 de agosto…

---

PATO.  ¡Oh no!

Creo que el centavo acaba de caer...

---

DOUG.  Ni siquiera tengo que decir el año!

11 de agosto de 2003: el mundo se percató del gusano Blaster, que afectó a los sistemas Windows 2000 y Windows XP.

Blaster, también conocido como Lovesan y MsBlast, explotó un desbordamiento de búfer y quizás sea mejor conocido por el mensaje, “Billy Gates, ¿por qué haces esto posible? Deje de ganar dinero y arregle su software”.

¿Qué pasó, Pablo?

---

PATO.  Bueno, fue la era anterior, quizás, nos tomamos la seguridad tan en serio.

Y, afortunadamente, ese tipo de error sería mucho, mucho más difícil de explotar en estos días: era un desbordamiento de búfer basado en la pila.

Y si no recuerdo mal, las versiones de servidor de Windows ya se estaban construyendo con lo que se llama protección de pila.

En otras palabras, si desborda la pila dentro de una función, entonces, antes de que la función regrese y haga el daño con la pila corrupta, detectará que algo malo ha sucedido.

Por lo tanto, tiene que cerrar el programa infractor, pero el malware no se ejecuta.

Pero esa protección no estaba en las versiones cliente de Windows en ese momento.

Y según recuerdo, era uno de esos primeros malwares que tenía que adivinar qué versión de sistema operativo tenías.

estas en el 2000? ¿Estás en NT? ¿Estás en XP?

Y si se equivocó, una parte importante del sistema fallaría y recibiría la advertencia "Su sistema está a punto de cerrarse".

---

DOUG.  Ja, me acuerdo de esos!

---

PATO.  Entonces, estaba ese daño colateral que era, para muchas personas, la señal de que te estaban golpeando las infecciones…

…que podría ser del exterior, como si fueras un usuario doméstico y no tuvieras un enrutador o un cortafuegos en casa.

Pero si estaba dentro de una empresa, el ataque más probable provendría de otra persona dentro de la empresa, lanzando paquetes en su red.

Entonces, muy parecido al ataque de CodeRed del que hablamos, que fue un par de años antes de eso, en un podcast reciente, el problema era realmente la gran escala, el volumen y la velocidad de esta cosa.

---

DOUG.  Está bien, bueno, eso fue hace unos 20 años.

Y si hacemos retroceder el reloj a hace cinco años, entonces es cuando Slack comenzó a filtrarse contraseñas cifradas. [LA RISA]

---

PATO.  Sí, Slack, la popular herramienta de colaboración...

…tiene una función en la que puede enviar un enlace de invitación a otras personas para que se unan a su espacio de trabajo.

E imagina: haces clic en un botón que dice "Generar un enlace", y creará algún tipo de paquete de red que probablemente tenga algo de JSON dentro.

Si alguna vez recibió una invitación a una reunión de Zoom, sabrá que tiene una fecha, una hora, la persona que lo invita, una URL que puede usar para la reunión, un código de acceso y todo eso. cosas: tiene bastantes datos allí.

Normalmente, no profundiza en los datos sin procesar para ver qué hay allí: el cliente simplemente dice: “Oye, aquí hay una reunión, aquí están los detalles. ¿Quiere aceptar/tal vez/rechazar?”

Resultó que cuando hiciste esto con Slack, como dices, durante más de cinco años, en esa invitación había datos superfluos que no eran estrictamente relevantes para la invitación en sí.

Entonces, ni una URL, ni un nombre, ni una fecha, ni una hora…

…pero el *hash de la contraseña del usuario que invita* [RISAS]

---

DOUG.  Hmmmmm

---

PATO.  ¡No es broma!

---

DOUG.  Eso suena mal…

---

PATO.  Sí, realmente lo hace, ¿no es así?

La mala noticia es, ¿cómo diablos llegó eso allí?

Y, una vez que estuvo allí, ¿cómo diablos evadió la atención durante cinco años y tres meses?

De hecho, si visitas el artículo sobre Naked Security y miras el URL completa del artículo, notará que dice al final, blahblahblah-for-three-months.

¡Porque, cuando leí el informe por primera vez, mi mente no quería verlo como 2017! [LA RISA]

Fue del 17 de abril al 17 de julio, por lo que había muchos "17" allí.

Y mi mente dejó en blanco el 2017 como el año de inicio; lo malinterpreté como "de abril a julio *de este año*" [2022].

Pensé: "Vaya, *tres meses* y no se dieron cuenta".

Y luego el primer comentario sobre el artículo fue, “Ejem [TOS]. En realidad, fue el 17 de abril de *2017*”.

¡Wow!

Pero alguien lo descubrió el 17 de julio [2022], y Slack, para su crédito, lo arregló el mismo día.

Como, "¡Oh, Dios mío, ¡¿en qué estábamos pensando ?!"

Así que esa es la mala noticia.

La buena noticia es que al menos eran contraseñas *hash*.

Y no solo se codificaron, sino que se *salaron*, que es donde se mezclan datos aleatorios por usuario elegidos de forma única con la contraseña.

La idea de esto es doble.

Primero, si dos personas eligen la misma contraseña, no obtienen el mismo hash, por lo que no puede hacer ninguna inferencia mirando la base de datos de hash.

Y dos, no puede calcular previamente un diccionario de valores hash conocidos para entradas conocidas, porque tiene que crear un diccionario separado para cada contraseña *para cada sal*.

Por lo tanto, no es un ejercicio trivial descifrar contraseñas cifradas.

Habiendo dicho eso, la idea general es que no se supone que sean un asunto de registro público.

Están triturados y salados *en caso* de que se filtren, no *para que puedan* filtrarse.

Entonces, ¡huevo en la cara de Slack!

Slack dice que aproximadamente uno de cada 200 usuarios, o el 0.5%, se vio afectado.

Pero si eres un usuario de Slack, asumiría que si no se dieron cuenta de que estuvieron filtrando contraseñas hash durante cinco años, tal vez tampoco enumeraron completamente la lista de personas afectadas.

Entonces, vaya y cambie su contraseña de todos modos ... también podría hacerlo.

---

DOUG.  Bien, también decimos: si no está utilizando un administrador de contraseñas, considere obtener uno; y active 2FA si puede.

---

PATO.  Pensé que te gustaría eso, Doug.

---

DOUG.  ¡Sí!

Y luego, si eres Slack o una empresa similar, elige un algoritmo de salt-hash-and-stretch de buena reputación cuando maneje usted mismo las contraseñas.

---

PATO.  Sí.

El gran problema en la respuesta de Slack, y lo que pensé que faltaba, es que simplemente dijeron: "No se preocupen, no solo codificamos las contraseñas, también las agregamos".

Mi consejo es que si se ve atrapado en una infracción como esta, debería estar dispuesto a declarar el algoritmo o proceso que usó para saltear y hash, y también idealmente cómo se llama se extiende, que es donde no solo codifica la contraseña con sal una vez, sino que tal vez la codifica 100,000 XNUMX veces para ralentizar cualquier tipo de diccionario o ataque de fuerza bruta.

Y si indicas qué algoritmo estás usando y con qué parámetros... por ejemplo, PBKDF2, bcrypt, scrypt, Argon2 – esos son los algoritmos de contraseña “salt-hash-stretch” más conocidos que existen.

Si realmente indicas qué algoritmo estás usando, entonces: [A] estás siendo más abierto y [B] estás dando a las posibles víctimas del problema la oportunidad de evaluar por sí mismas cuán peligroso creen que podría haber sido esto. .

Y ese tipo de apertura en realidad puede ayudar mucho.

Slack no hizo eso.

Simplemente dijeron: "Oh, estaban salados y triturados".

Pero lo que no sabemos es si pusieron dos bytes de sal y luego los trituraron una vez con SHA-1...

…o tenían algo un poco más resistente al agrietamiento?

---

DOUG.  Siguiendo con el tema de las cosas malas, estamos notando una tendencia en desarrollo en la que las personas son inyectando cosas malas en GitHub, solo para ver que pasa, exponiendo riesgo…

…tenemos otra de esas historias.

---

PATO.  Sí, alguien que ahora supuestamente salió en Twitter y dijo: “No se preocupen chicos, no hay daño. Era solo para investigar. Voy a escribir un informe, destacarme de Blue Alert”.

Crearon literalmente miles de proyectos falsos de GitHub, basados ​​en la copia de código legítimo existente, insertando deliberadamente algunos comandos de malware allí, como "llamar a casa para obtener más instrucciones" e "interpretar el cuerpo de la respuesta como código de puerta trasera para ejecutar", y pronto.

Entonces, cosas que realmente podrían hacer daño si instalaste uno de estos paquetes.

Dándoles nombres que parecen legítimos...

…tomando prestado, aparentemente, el historial de confirmación de un proyecto genuino para que la cosa pareciera mucho más legítima de lo que cabría esperar si solo apareciera con, “Oye, descarga este archivo. ¡Sabes que quieres!"

¡¿En realidad?! ¿¿Investigar?? ¿No sabíamos esto ya?!!?

Ahora, puede argumentar: "Bueno, Microsoft, que posee GitHub, ¿qué están haciendo para que sea tan fácil para las personas cargar este tipo de cosas?"

Y hay algo de verdad en eso.

Tal vez podrían hacer un mejor trabajo al mantener alejado el malware en primer lugar.

Pero es un poco exagerado decir: "Oh, todo es culpa de Microsoft".

En mi opinión, es aún peor decir: “Sí, esta es una investigación genuina; esto es realmente importante; tenemos que recordarle a la gente que esto podría suceder”.

Bueno, [A] eso ya lo sabemos, muchas gracias, porque mucha gente ha hecho esto antes; recibimos el mensaje alto y claro.

Y [B] esto *no* es investigación.

Esto está tratando deliberadamente de engañar a las personas para que descarguen un código que le da a un posible atacante control remoto, a cambio de la capacidad de escribir un informe.

Eso me suena más a una "excusa grande y gorda" que a un motivador legítimo para la investigación.

Así que mi recomendación es, si crees que esto *es* investigación, y si estás decidido a hacer algo como esto de nuevo, *no esperes mucha simpatía* si te atrapan.

---

DOUG.  Muy bien, volveremos a esto y a los comentarios del lector al final del programa, así que quédense.

Pero primero, hablemos de semáforos, y lo que tienen que ver con la ciberseguridad.

---

PATO.  ¡Ahhh, sí! [RISA]

Bueno, hay una cosa llamada TLP, el Protocolo de semáforo.

Y el TLP es lo que podría llamarse un "protocolo de investigación de ciberseguridad humana" que lo ayuda a etiquetar los documentos que envía a otras personas, para darles una pista de lo que espera que hagan (y, lo que es más importante, lo que espera que hagan * no*) hacer con los datos.

En particular, ¿cuán ampliamente se supone que deben redistribuirlo?

¿Es esto algo tan importante que podrías declararlo al mundo?

¿O es esto potencialmente peligroso, o incluye potencialmente algunas cosas que no queremos que sean públicas todavía... así que guárdatelo para ti?

Y comenzó con: TLP:RED, que significaba, “Guárdatelo para ti mismo”; TLP:AMBER, que significaba “Puedes circularlo dentro de tu propia empresa o a clientes tuyos que creas que puedan necesitar urgentemente saber esto”; TLP:GREEN, lo que significaba: "Está bien, puede dejar que esto circule ampliamente dentro de la comunidad de ciberseguridad".

Y TLP:WHITE, que significaba: "Puedes decírselo a cualquiera".

Muy útil, muy simple: ROJO, ÁMBAR, VERDE… una metáfora que funciona globalmente, sin preocuparse de cuál es la diferencia entre “secreto” y “confidencial” y cuál es la diferencia entre “confidencial” y “clasificado”, todas esas cosas complicadas que necesita un montón de leyes a su alrededor.

Bueno, el TLP acaba de recibir algunas modificaciones.

Entonces, si está interesado en la investigación de seguridad cibernética, asegúrese de conocerlos.

TLP:WHITE se ha cambiado a lo que considero un término mucho mejor en realidad, porque complejo de salvador blanco tiene todos estos matices culturales innecesarios de los que podemos prescindir en la era moderna.

¿Entonces TLP:WHITE acaba de convertirse TLP:CLEAR, que, en mi opinión, es una palabra mucho mejor porque dice: "Tiene autorización para usar estos datos", y esa intención se expresa, ejem, muy claramente. (Lo siento, no pude resistir el juego de palabras).

Y hay una capa adicional (así que ha estropeado un poco la metáfora: ¡ahora es un semáforo de *cinco* colores!).

Hay un nivel especial llamado TLP:AMBER+STRICT, y lo que eso significa es: "Puedes compartir esto dentro de tu empresa".

Por lo tanto, es posible que lo inviten a una reunión, tal vez trabaje para una empresa de seguridad cibernética, y está bastante claro que deberá mostrar esto a los programadores, tal vez a su equipo de TI, tal vez a su gente de control de calidad, para que pueda investigar el problema o tratar de solucionarlo.

Pero TLP:AMBER+STRICT significa que, aunque puede distribuirlo dentro de su organización, *no se lo diga a sus clientes ni a sus clientes*, ni siquiera a personas ajenas a la empresa que crea que podrían necesitar saber.

Mantenlo dentro de la comunidad más estrecha para empezar.

TLP:AMBER, como antes, significa: "Está bien, si siente que necesita decírselo a sus clientes, puede hacerlo".

Y eso puede ser importante, porque a veces es posible que desee informar a sus clientes: “Oye, tenemos la solución en camino. Deberá tomar algunas medidas de precaución antes de que llegue la solución. Pero debido a que es un poco sensible, ¿podemos pedirle que no se lo diga al mundo todavía?

A veces, decirle al mundo demasiado pronto en realidad juega más a favor de los ladrones que de los defensores.

Entonces, si eres un respondedor de seguridad cibernética, te sugiero que vayas: https://www.first.org/tlp

---

DOUG.  Y tu puedes leer más sobre eso en nuestro sitio, desnudaseguridad.sophos.com.

Y si está buscando alguna otra lectura ligera, olvídese de la criptografía cuántica... pasamos a criptografía post-cuántica, ¡Pablo!

---

PATO.  Sí, ya hemos hablado de esto varias veces en el podcast, ¿no?

La idea de una computadora cuántica, suponiendo que se pueda construir una lo suficientemente poderosa y confiable, es que ciertos tipos de algoritmos podrían acelerarse sobre el estado del arte actual, ya sea con la melodía de la raíz cuadrada... o peor aún, la *logaritmo* de la escala del problema hoy.

En otras palabras, en lugar de tomar 2²⁵⁶ intenta encontrar un archivo con un hash en particular, es posible que pueda hacerlo en solo ("¡solo"!) 2¹²⁸ intentos, que es la raíz cuadrada.

Claramente mucho más rápido.

Pero hay toda una clase de problemas relacionados con la factorización de productos de números primos que, según la teoría, podrían descifrarse en el *logaritmo* del tiempo que tardan hoy, en términos generales.

Entonces, en lugar de tomar, digamos, 2¹²⁸ días para romperse [MUCHO MÁS QUE LA EDAD ACTUAL DEL UNIVERSO], podría tomar solo 128 días para romperse.

O puede reemplazar "días" con "minutos", o lo que sea.

Y desafortunadamente, ese algoritmo de tiempo logarítmico (llamado Algoritmo de factorización cuántica de Shor)… eso podría, en teoría, aplicarse a algunas de las técnicas criptográficas actuales, en particular las que se utilizan para la criptografía de clave pública.

Y, en caso de que estos dispositivos de computación cuántica se vuelvan factibles en los próximos años, ¿tal vez deberíamos comenzar a prepararnos ahora para algoritmos de cifrado que no sean vulnerables a estas dos clases particulares de ataque?

En particular, el logaritmo, porque acelera tanto los posibles ataques que las claves criptográficas que actualmente pensamos: "Bueno, nadie lo descubrirá jamás", podrían revelarse en una etapa posterior.

De todos modos, NIST, el Instituto Nacional de Estándares y Tecnología en los EE. UU., ha estado organizando durante varios años una competencia para tratar de estandarizar algunos algoritmos públicos, no patentados y bien analizados que serán resistentes a estas computadoras cuánticas mágicas, si alguna vez aparecen.

Y recientemente eligieron cuatro algoritmos que ahora están preparados para estandarizar.

Tienen nombres geniales, Doug, así que tengo que leerlos: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONy SPHINCS+. [LA RISA]

Entonces tienen nombres geniales, si nada más.

Pero, al mismo tiempo, el NIST pensó: “Bueno, son solo cuatro algoritmos. Lo que haremos es elegir a cuatro más como posibles candidatos secundarios, y veremos si alguno de ellos debería pasar también”.

Así que ahora hay cuatro algoritmos estandarizados y cuatro algoritmos que podrían estandarizarse en el futuro.

O *eran* cuatro el 5 de julio de 2022, y uno de ellos era SIKE, corto para encapsulación de clave de isogenia supersingular.

(Necesitaremos varios podcasts para explicar las isogenias supersingulares, así que no nos molestaremos. [RISAS])

Pero, desafortunadamente, este, que estaba allí con una posibilidad de lucha por ser estandarizado, parece que se ha roto irremediablemente, a pesar de haber estado abierto al escrutinio público durante al menos cinco años.

Entonces, afortunadamente, justo antes de que se estandarizara o pudiera estandarizarse, dos criptógrafos belgas se dieron cuenta: “¿Saben qué? Creemos que tenemos una forma de evitar esto usando cálculos que toman alrededor de una hora, en una CPU bastante promedio, usando solo un núcleo”.

---

DOUG.  Supongo que es mejor averiguarlo ahora que después de estandarizarlo y sacarlo a la luz.

---

PATO.  ¡Ciertamente!

Supongo que si hubiera sido uno de los algoritmos que ya se estandarizaron, ¿tendrían que derogar el estándar y crear uno nuevo?

Parece extraño que esto no se haya notado durante cinco años.

Pero supongo que esa es la idea del escrutinio público: nunca se sabe cuándo alguien podría dar con la grieta que se necesita, o la pequeña cuña que pueden usar para entrar y demostrar que el algoritmo no es tan fuerte como se pensó originalmente.

Un buen recordatorio de que si *alguna vez* pensó en tejer su propia criptografía...

---

DOUG.  [RISAS] ¡No lo he hecho!

---

PATO.  ..a pesar de que le dijimos en el podcast de Naked Security N veces, "¡No hagas eso!"

Este debería ser el último recordatorio de que, incluso cuando los verdaderos expertos lanzan un algoritmo que está sujeto al escrutinio público en una competencia global durante cinco años, esto no necesariamente brinda suficiente tiempo para exponer fallas que resultan ser bastante malas.

Entonces, ciertamente no se ve bien para esto SIKE algoritmo.

Y quién sabe, ¿tal vez sea retirado?

---

DOUG.  Estaremos atentos a eso.

Y a medida que el sol se pone lentamente en nuestro programa de esta semana, es hora de escuchar a uno de nuestros lectores sobre la historia de GitHub que discutimos anteriormente.

Robar escribe:

“Hay algo de tiza y queso en los comentarios, y odio decirlo, pero realmente puedo ver ambos lados del argumento. ¿Es peligroso, problemático, una pérdida de tiempo y consume recursos? Sí, por supuesto que lo es. ¿Es lo que harían los tipos de mentalidad criminal? Sí, así es. ¿Es un recordatorio para cualquiera que use GitHub, o cualquier otro sistema de depósito de código, de que viajar de manera segura en Internet requiere un grado saludable de cinismo y paranoia? Sí. Como administrador de sistemas, una parte de mí quiere aplaudir la exposición del riesgo en cuestión. Como administrador de sistemas de un grupo de desarrolladores, ahora debo asegurarme de que todos hayan buscado entradas cuestionables recientemente en las extracciones".

---

PATO.  Sí, gracias, RobB, por ese comentario, porque supongo que es importante ver ambos lados del argumento.

Hubo comentaristas que solo decían: “¿Cuál diablos es el problema con esto? ¡Esto es genial!"

Una persona dijo, “No, en realidad, esta prueba de penetración es buena y útil. Alégrate de que estos estén siendo expuestos ahora en lugar de asomar su fea cabeza ante un atacante real”.

Y mi respuesta a eso es que, "Bueno, esto *es* un ataque, en realidad".

Es que ahora alguien ha salido después, diciendo “Oh, no, no. ¡Ningún daño hecho! Honestamente, no estaba siendo travieso”.

¡No creo que estés obligado a comprar esa excusa!

Pero de todos modos, esto no es una prueba de penetración.

Mi respuesta fue decir, muy simplemente: "Los probadores de penetración responsables solo actúan [A] después de recibir un permiso explícito, y [B] dentro de los límites de comportamiento acordados explícitamente por adelantado".

Usted no se limita a inventar sus propias reglas, y ya hemos discutido esto antes.

Entonces, como dijo otro comentarista, que es, creo, mi comentario favorito... Ecurb dijo, “Creo que alguien debería caminar de casa en casa y romper ventanas para mostrar lo ineficaces que son las cerraduras de las puertas. Esto está vencido. Alguien salte sobre esto, por favor.

Y luego, en caso de que no se dieran cuenta de que era una sátira, amigos, dice: "¡No!"

---

PATO.  Tengo la idea de que es un buen recordatorio, y tengo la idea de que si eres un usuario de GitHub, tanto como productor como consumidor, hay cosas que puedes hacer.

Los enumeramos en los comentarios y en el artículo.

Por ejemplo, coloque una firma digital en todas sus confirmaciones para que sea obvio que los cambios provienen de usted y que haya algún tipo de trazabilidad.

Y no se limite a consumir cosas a ciegas porque hizo una búsqueda y "parecía" que podría ser el proyecto correcto.

Sí, todos podemos aprender de esto, pero ¿esto realmente cuenta como una enseñanza, o es algo que deberíamos aprender de todos modos?

Creo que esto *no* es enseñar.

Simplemente *no tiene un estándar lo suficientemente alto* para contar como investigación.

---

DOUG.  Gran discusión sobre este artículo, y gracias por enviarlo, Rob.

Si tiene una historia interesante, un comentario o una pregunta que le gustaría enviar, nos encantaría leerlo en el podcast.

Puedes enviar un correo a tips@sophos.com; puedes 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 y les recuerdo, hasta la próxima, que...

---

AMBAS COSAS.  ¡Mantente seguro!

[MÓDEM MUSICAL]