La popular herramienta de colaboración Slack (que no debe confundirse con el apodo de la distro de Linux más longeva del mundo, Slackware) acaba de admitir un largo SNAFU de ciberseguridad.
Según un boletín de noticias titulado Aviso sobre el restablecimiento de la contraseña de Slack, la empresa admitió que había estado compartiendo inadvertidamente datos personales “cuando los usuarios creaban o revocaban un enlace de invitación compartida para su espacio de trabajo.”
Desde el 17/4/2017 hasta el 17/7/2022 (suponemos que ambas fechas son inclusive), Slack dijo que los datos enviados a los destinatarios de dichas invitaciones incluían la contraseña ccifrada del remitente.
¿Qué falló?
El aviso de seguridad de Slack no explica la brecha con mucha claridad, diciendo simplemente que “esta contraseña cifrada no era visible para ningún cliente de Slack, descubrirla requirió monitorear activamente el tráfico de red cifrado proveniente de los servidores de Slack”.
Suponemos que esto se traduce de la siguiente manera:
“La mayoría de los destinatarios no se habrían dado cuenta de que los datos que recibían incluían información sobre la contraseña cifrada, porque esa información, aunque estaba incluida en los paquetes de red enviados, nunca se les mostró deliberadamente. Y como los datos se enviaron a través de una conexión TLS, los fisgones no habrían podido husmearlos por el camino, porque no se descifrarían hasta llegar al otro extremo de la conexión”.
Esa es la buena noticia.
Pero los paquetes de red suelen incluir datos que normalmente no son utilizados ni vistos por los destinatarios.
Las cabeceras HTTP son un buen ejemplo de ello, ya que están pensadas como instrucciones para el navegador, no como datos para mostrar en la página web que se está viendo.
Y los datos que son irrelevantes o invisibles para los usuarios a menudo terminan en los registros de todos modos, especialmente en los registros del firewall, donde podrían conservarse indefinidamente.
Esas son las malas noticias.
Salt, hash y stretch
Según Slack, los datos filtrados no sólo fueron sometidos a hash, sino también a salt, lo que significa que la contraseña de cada usuario se mezcló primero con datos aleatorios únicos para ese usuario antes de aplicar la función hash.
Los hash son esencialmente funciones matemáticas “no reversibles” que son fáciles de calcular en una dirección, pero no en la otra.
Por ejemplo, es fácil calcular que:
SHA256(“PATO”) = 7FB376..DEAD4B3AF008
Pero la única manera de trabajar “hacia atrás” desde 7FB376..DEAD4B3AF008 a PATO es trabajar hacia adelante desde cada palabra posible del diccionario y ver si alguna de ellas sale con el valor que estás tratando de igualar:
SHA256(“AARDVARK”) = 5A9394..467731D0526A [X]
SHA256(“AARON”) = C4DDDE..12E4CFE7B4FD [X]
SHA256(“ABACUS”) = BEDDD8..1FE4DE25AAD7 [X]
. . . 3400 omitidos
SHA256(“BALBUCEO”) = 70E837..CEAD4B1FA777 [X]
SHA256(“TEJÓN”) = 946D0D..7B3073C1C094 [X]
SHA256(“GAITA”) = 359DBE..BE193FCCB111 [X]
. . . 3200 omitidos
SHA256(“CABAL”) = D78CF4..85BE02967565 [X]
SHA256(“CACHE”) = C118F9..22F3269E7B32 [X]
SHA256(“CAGOULE”) = 5EA530..5A26C5B56DCF [X]
. . . 5400 omitidos
SHA256(“DAB”) = BBCC8E..E8B98CAB5128 [X]
SHA256(“NARCISO”) = 75121D..D6401AB24A98 [X]
SHA256(“PELIGRO”) = 0BD727..4C86037BB065 [X]
. . . 3500 omitidos
SHA256(“DUCK”) = 7FB376..DEAD4B3AF008 [¡ENCONTRADO!]
Y al incluir un salt por usuario, que no necesita ser secreto, simplemente único para cada usuario, te aseguras que incluso si dos usuarios eligen la misma contraseña, no terminarán con el mismo hash de la contraseña.
Puedes ver el efecto del salting aquí, cuando hacemos el hash de la palabra DUCK con tres prefijos diferentes:
SHA256(“RANDOM1-DUCK”) = E355DB..349E669BB9A2
SHA256(“RANDOM2-DUCK”) = 13D538..FEA0DC6DBB5C <– El cambio de un solo byte de entrada produce un hash muy diferente
SHA256(“ARXXQ3H-DUCK”) = 52AD92..544208A19449
Esto también significa que los atacantes no pueden crear una lista precalculada de hashes probables, o crear una tabla de cálculos parciales de hash, conocida como tabla arcoíris, que puede acelerar la comprobación del hash. (Necesitarían una nueva lista de hash, o un conjunto único de tablas arcoíris, para cada salt posible).
En otras palabras, las contraseñas con hash y salt no pueden ser descifradas fácilmente para recuperar la entrada original, especialmente si la contraseña original era compleja y elegida al azar.
Lo que Slack no ha dicho es si también han realizado un stretch de los hash de las contraseñas, y si es así, cómo.
Stretch es un término de que significa repetir el proceso de hash de la contraseña una y otra vez, por ejemplo, 100.000 veces, con el fin de ampliar el tiempo necesario para probar un montón de palabras del diccionario contra hash de contraseñas conocidas.
Si se tardara un segundo en someter 100.000 palabras del diccionario a un proceso simple de salt y hash, entonces los atacantes que conozcan el hash de tu contraseña podrían probar 6 millones de palabras del diccionario diferentes y derivadas cada minuto, o hacer más de mil millones de conjeturas cada tres horas.
Por otro lado, si los cálculos de la salt y el hash se extendieran a un segundo cada uno, entonces el retraso extra de un segundo cuando intentara iniciar sesión le causaría poca o ninguna molestia pero reduciría a sólo 3.600 intentos por hora, lo que haría mucho menos probable que tuviera tiempo suficiente para adivinar cualquier cosa que no fueran las contraseñas más obvias.
Se conocen varios algoritmos muy respetados de “salt-hash-and-stretch”, especialmente PBKDF2, bcrypt, scrypt y Argon2, todos los cuales pueden ajustarse para aumentar el tiempo necesario para intentar adivinar contraseñas individuales con el fin de reducir la viabilidad de los llamados ataques de diccionario y de fuerza bruta.
Un ataque de diccionario significa que intentas sólo contraseñas probables, como todas las palabras que se te ocurran desde “aba” hasta “zuzón”, y luego te rindes. Un ataque de fuerza bruta significa probar todas las entradas posibles, incluso las más extrañas e impronunciables, desde AAA..AAAA hasta ZZZ..ZZZZ (o desde 0000..000000 hasta FFFF..FFFFFF si piensas en términos hexadecimales byte a byte).
¿Qué hacer?
Slack dice que están afectados alrededor de 1 de cada 200 de sus usuarios (0,5%, presumiblemente basado en los registros de cuántos enlaces de invitación compartida se generaron en el período de peligro), y que va a obligar a esos usuarios a restablecer sus contraseñas.
Un consejo más:
- Si eres un usuario de Slack, es mejor que restablezcas tu contraseña aunque no hayas sido notificado por la empresa para hacerlo. Cuando una empresa admite que ha sido descuidada con su base de datos de contraseñas al filtrar los hashtags, especialmente durante un período tan largo, es mejor que asumas que la tuya se ha visto afectada, aunque la empresa crea que no. En cuanto cambias tu contraseña, haces que el antiguo hash sea inútil para los atacantes.
- Si no utilizas un gestor de contraseñas, considera la posibilidad de adquirir uno. Un gestor de contraseñas ayuda a elegir las contraseñas adecuadas, asegurando así que tu contraseña acabe muy, muy abajo en la lista de contraseñas que podrían ser descifradas en un incidente como éste. Los atacantes normalmente no pueden realizar un verdadero ataque de fuerza bruta, porque hay demasiadas contraseñas posibles que probar. Por eso, primero prueban las contraseñas más probables, como palabras o combinaciones obvias de palabras y números, que se van haciendo más largas y complejas a medida que avanza el ataque. Un gestor de contraseñas puede recordar una contraseña aleatoria de 20 caracteres con la misma facilidad con la que tú puedes recordar el nombre de tu gato.
- Activa el 2FA si puedes. 2FA, o autenticación de dos factores, significa que no sólo necesitas tu contraseña para iniciar sesión, sino también un código de un solo uso que cambia cada vez. Estos códigos suelen enviarse a tu teléfono móvil (o ser generados por él) y sólo son válidos durante unos minutos. Esto significa que incluso si los ciberdelincuentes descifran tu contraseña, no es suficiente por sí sola para hacerse con tu cuenta.
- Elige un algoritmo de sal-hash-y-stretch de buena reputación cuando manejes las contraseñas tú mismo. En el desafortunado caso de que tu base de datos de contraseñas sea violada, podrás dar a sus clientes detalles precisos sobre el algoritmo y la configuración de seguridad que se utilizó. Esto ayudará a los usuarios bien informados a juzgar por sí mismos la probabilidad de que sus hashtags robados hayan sido descifrados en el tiempo disponible para los atacantes hasta ahora.
Dejar un comentario