Nuevas vulnerabilidades en Linux permiten robar el hash de contraseñas desde core dumps

Un atacante local podía forzar el volcado de memoria de un programa SUID y, antes de que se restringieran los permisos del archivo, leer el contenido para extraer hashes de /etc/shadow, lo que abre la puerta a la elevación de privilegios tras su criptoanálisis.

[#7 eltoloco]

#6 para eso está el salt, para añadir aleatoriedad y entre otras cosas evitar que se crucen datos con otras bases de datos de hashes.

en.wikipedia.org/wiki/Salt_(cryptography)

[#9 DayOfTheTentacle]

#7 Solo multiplica las opciones... Si el password es "mipass1234" cuantos hashes diferentes puede producir?

[#11 eltoloco]

#9 para una misma contraseña hay tantos hashes diferentes como salts diferentes haya, es decir, infinitos.

El hash se calcula a partir de la concatenación de salt + password. Ejemplo:

- hash(salt1mipass1234)
- hash(salt2mipass1234)
...
- hash(salt99999mipass1234)

[#14 DayOfTheTentacle]

#11 como ves no se de estas cosas...

entonces para luego validarla, como sabes cual era el salt? es decir yo pongo login y pass (mipass1234) y como sabe que tiene que ponerle el salt33 o el salt 666 para que coincida con lo que tiene guardado encriptado? #12

[#18 chavi]

#14 Y no hace falta que sea la mlsma, si genera el mismo hash, vale.

[#21 eltoloco]

#18 eso ocurría con algoritmos de hash que están más que obsoletos, los algoritmos modernos y seguros no tienen colisiones, o más bien es de nuevo estadísticamente imposible que ocurra una colisión

[#31 chavi]

#21 Todos tienen colisiones. Es inevitable.

Otro tema es que se puedan generar de forma previsible....

Hasta hace nada encontrar las contraseñas de Windows era trivial. No se hoy...

es.m.wikipedia.org/wiki/Tabla_arcoíris

[#35 eltoloco]

#31 no, no es así. Estás mezclando funciones de hash simples y/o que están totalmente obsoletas, como por ejemplo MD5 o SHA1, con funciones que son 100% seguras y donde nunca se ha encontrado una sola colisión, como por ejemplo SHA256 que se usa actualmente en todo tipo de sistemas de seguridad, como JWT, TLS o blockchain.

Si de verdad crees que SHA256 es inseguro no se porque todavía no te has hecho millonario, pues rompiendo la criptografía podrías hacer lo que te diese la gana, como por…   

[#36 chavi]

#35 Estamos hablando de contraseñas.

Sigue siendo vulnerable Windows a las Rainbow Tables?

[#37 eltoloco]

#36 no, estamos hablando de hashes y de colisiones. Que Windows tenga un sistema de seguridad de mierda no quiere decir que los algoritmos de hash modernos no sean seguros. Estás haciendo una falacia del hombre de paja.

[#38 chavi]

#37 Mira el titular y el hilo, anda...
Hablamos de los hashes de las contraseñas de los sistemas

[#41 eltoloco]

#38 efectivamente, hablamos de hashes seguros en Linux, no de rainbow tables para atacar Windows, que es una gran puta mierda en seguridad.

Las rainbow tables son tablas con hashes precomputados para contraseñas conocidas, por lo tanto es un ataque de ingeniería social, que solo sirve si no usas ningún salt, nada más y nada menos.

[#45 chavi]

#41 Ataque de fuerza bruta, no de ingenieria social.
Y me temo que aunque en distinto grado los hashes de las pass de Linux tambien ofrecen vulnerabilidades a este tipo de ataques

[#39 Marx]

#35 SHA256 tiene 2²⁵⁶ combinaciones posibles pero contraseñas hay infinitas y como infinito es mayor que 2²⁵⁶, por huevos y por definición, SHA256 tiene colisiones, de hecho tiene infinitas colisiones.

Tema a parte es que sea viable encontrar una colisión.

Y si estoy equivocado, explícame cómo con 2²⁵⁶ posibles combinaciones puedes representar infinitas contraseñas para que no puedan existir colisiones.

[#40 eltoloco]

#39 por eso he dicho que es computacionalmente imposible encontrar colisiones, no matematicamente.

El problema es que para la mente humana es imposible de entender la magnitud del numero 2^256, que es un numero enorme, de casi 80 cifras:

1.1579209e+77 = 1157920 9xxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx

Para llegar a tener ese número diferentes de hashes usando contraseñas hexadecimales, necesitas comprobar un número también tremendo de posibilidades, lo…   

[#42 Marx]

#40 Lo que dices es correcto y estoy de acuerdo, tan solo que lo que dijo el otro también es correcto pues dijo:

Todos tienen colisiones. Es inevitable.

Otro tema es que se puedan generar de forma previsible....

Que viene a ser lo que tú dices aquí: es computacionalmente imposible encontrar colisiones, no matematicamente.

Eso es lo que entendí yo de él, que por definición todos tienen colisiones pero tema aparte es que se puedan encontrar.

Dicho de otro modo: www.youtube.com/shorts/TWL9kB4-aP8

[#43 eltoloco]

#42 no, lo que dijo #31 es que se han encontrado colisiones en todas las funciones de hash, lo cual es falso, tanto que se puedan generar de forma previsible como él dice, como directamente que se puedan generar.

Por mucho que matemáticamente haya colisiones, la realidad es que a día de hoy no hay ningún sistema factible para encontrar colisiones con SHA256 ni muchísimo menos con SHA512, entre otros. Obviamente si pones un supercomputador a calcular todas las posibilidades acabarás…     

[#44 Marx]

#43 No quisiera enfrascarme en una discusión, lo que dijo #31 es lo que literalmente está escrito, que es:

"#21 Todos tienen colisiones. Es inevitable.

Otro tema es que se puedan generar de forma previsible....

Hasta hace nada encontrar las contraseñas de Windows era trivial. No se hoy...

es.m.wikipedia.org/wiki/Tabla_arcoíris"

En ninguna parte de ese comentario dijo que "se han encontrado colisiones en todas las funciones de hash," sino simplemente que…   

[#19 chochis]

#14 Los hay que guardan la salt por separado y los hay que guardan la salt dentro del propio hash como bcrypt y Argon2.
Estos lo que hacen es que les sacan la salt y la versión del hasheado del hash anterior y comprobar que las passwords son iguales usando el hash

[#23 DayOfTheTentacle]

#19 entonces si es posible sacar el salt, volvemos a tener el mismo problema no?

[#24 chochis]

#23 No exactamente, ya que tendrías que tener infinitas rainbow tables, tantas como salts.

[#25 chochis]

#23 a ver si me explico mejor:

Imagínate una password: 1234
Y un algorítmo: Argon2

Lo que se archiva es esto: DayOfTheTentacle -> Hash(version_argon2(id y version),configuración_usada,salt,hash_calculado_usando_el_salt)
Lo que hace el sistema es mirar tu usuario y decirle, DayOfTheTentacle ha escrito este password: password, aquí tienes el hash almacenado en el archivo de usuarios.
Entonces, desmonta el Hash sacado la salt y mirando si el password mas la salt dan el mismo resultado.
Lo que hace la salt es que añade una aleatoriedad infinita al hash, deberías de tener una rainbow table para ese salt.
Imagínate que por cada salt creado de 64bits de Argon2 existe una base de datos con los password mas comunes.

[#26 DayOfTheTentacle]

#25 y no se puede consultar ese salt cual es? dónde y como se guarda?

me pierdo, lo siento.

[#27 chochis]

#26 como te digo, se puede consultar. Es parte del archivo de guardado de los passwords.

[#28 DayOfTheTentacle]

#27 Entonces si se consulta esto + passwords aleatorio puedes construir una gran bbdd con muchas combinaciones. No es cosa de un día pero si tienes un servidor potente creando estas combinaciones 24h al día pues tendrás bastntes passwords creo yo.

[#29 chochis]

#28 no! Haz las mates!
Si tienes un salt de 128bits es 2^128. Imagínate! Para el mismo password tienes todas esas posibilidades

[#30 DayOfTheTentacle]

#29 Todos usan salts de 128 bits? sin duda saldría una bbdd con la que mysql sufriría pero vaya... gente con mucho dinero puede permitirse buenos servidores no?

[#32 chochis]

#30 Necesitas 340282366920938463463374607431768211456 tablas rainbow
Creo que mysql se ahoga un poco con esta cantidad de tablas

[#34 DayOfTheTentacle]

#32 nah, detalles

[#22 eltoloco]

#14 el salt está en el lado del servidor, y hay muchas formas de gestionarlo, desde la más básica de usar una constante, a usar un salt que sea relativo al usuario. Pero no me hagas mucho caso, que yo tampoco soy experto en seguridad, solo sé lo poco que vi en la carrera, y no hice la rama de seguridad. En el caso de Linux ni idea de como lo gestiona.

[#12 chochis]

#9 infinitos

[#20 eltoloco]

#17 para eso están los salt, go to #7

[#3 Jaime131]

¿Entonces este no va a ser el año de Linux en el escritorio?

[#1 O.OOЄ]

Desde hace siglos se recomienda que los procesos del usuario root no vuelquen core dumps, para lo cual hay que editar /etc/security/limits.

[#2 cenutrios_unidos]

#1 Sí pero yo además aconsejaría proteger la junta de la trócola.

[#5 janatxan]

#1 pues suerte que aspira a ser un sistema para la gran masa.

[#33 castel]

#5 Lo es.

[#8 pacote]

Un "atacante local"... dejo de leer y me digo parafraseando a Charlton Heston:
"Sólo me lo arrebatarán de mis frías y muertas manos".

No es irrelevante, pero sensacionalista desde luego pinta.

[#13 eltoloco]

#8 #10 que sea infinitamente más seguro que Windows y que las pocas vulnerabilidades que se encuentran en Linux sean en su mayoría restringidas a un atancante local, no significa que no haya que seguir trabajando para mejorar todavía más la seguridad.

Y en este caso de sensacionalista no tiene nada, pues se trata de un blog de seguridad informática, que no generalista, y está especificando desde el primer momento que se requiere acceso local. ¿Donde está el sensacionalismo?

[#15 pacote]

#13 Todos, repito TODOS los sistemas (mac, windows, linux, etc) son vulnerables si tienes acceso LOCAL al mismo, vamos, que puedes acariciarlo, lamerlo, olfatearlo, triturarlo, manipularlo y todo lo que se te ocurra.
Yo he perdido la cuenta de cuantos portátiles (Mac, windows, ...) han pasado por mis manos para resetearles la pass porque habían olvidado la contraseña.
¿Son por eso inseguros?. NO.

Lo dicho, sensacionalista, solo que aquí, en este método se han complicado un poco (sacar el hash... eso cuando las rainbow tables de passwords cortas y sin caracteres raros, era factible hacerlo hasta con una raspberry de primera generación, pero hoy en día con los salt eso es casi misión imposible, de poco o nada te van a servir esos hashes).

[#10 bibubibu]

Que es un puto atacante en local, hay que dejar de hacer aspavientos por cada tontada de asalto a Linux.

Así que voto sensacionalista como poco.

[#4 eltoloco]

¿Y de que sirve tener un hash de una contraseña? Los hashes modernos no se pueden revertir, es computacionalmente impracticable incluso con el superordenador más moderno y potente.

[#6 DayOfTheTentacle]

#4 revertir no pero fuerza bruta quién sabe si hay alguna bbdd con datos que se van generando hace la tira...

[#17 chavi]

#4 No hace falta revertirlos, se atacan con diccionarios.

[#16 alfema]

¿El artículo es una traducción automática?, ¿Qué es eso de aguas arriba?

"Otras distribuciones que usen systemd-coredump deberían incorporar el patch aguas arriba."