¿Cómo puede un atacante acceder a las contraseñas con hash?

48

La forma en que las contraseñas de hash y la fuerza de la contraseña son importantes porque si alguien obtiene acceso a las contraseñas de hash, es posible probar muchas y muchas contraseñas en un tiempo sorprendentemente corto y descifrar cualquier cosa que sea débil.

La pregunta que tengo es cómo es que el atacante tenga acceso a las contraseñas con hash en primer lugar. Si tienen acceso al archivo / etc / shadow, por ejemplo, ¿no está ya terminado el juego? ¿Es simplemente mala configuración de permisos? Copias de seguridad? Otros errores? ¿Es que una vez que un sistema se ve comprometido, la contraseña de allí se usa para intentar ingresar a otros sistemas?

Supongo que, en última instancia, mi consulta se reduce a la implicación que obtengo al leer sobre este tema que es inevitable que el atacante tenga acceso a los hashes. ¿Cómo sucede eso en la práctica?

    
pregunta JimmyJames 23.08.2016 - 16:30
fuente

5 respuestas

51

Hay varias formas de hacerlo:

  • inyección SQL
  • copias de seguridad filtradas
  • Empleados descontentos que los filtran
  • Cualquier tipo de infracción del servidor que permita la ejecución del código.

Como puede ver, hay muchas, muchas formas en que esto podría suceder, como phihag en los comentarios, más más de la mitad de los los 10 principales de OWASP podrían generar hashes filtrados, por lo que no se pueden tabular fácilmente en una publicar.

Esto no significa que sea inevitable que los piratas informáticos obtengan los hashes, pero aún debe usar un buen algoritmo de hash para protegerse y proteger a sus usuarios por si acaso. Ya que una copia de seguridad puede perderse o su servidor puede ser pirateado sin que usted lo note, el hecho de que las contraseñas estén bien ocultas debería ser lo único que le permita dormir por la noche. Esta estrategia se conoce como "defensa en profundidad" , o simplemente "planear para lo peor".

    
respondido por el Anders 23.08.2016 - 16:40
fuente
27

Hay muchos métodos. Aquí hay algunos que se me ocurren en la cabeza. Ahora puedo estar un poco mal con la sintaxis, ya que no me he molestado en probarlo ahora, pero en general, estas son cosas que harías para obtener esos datos.

Tenga en cuenta que, con las siguientes vulnerabilidades, no proporciono necesariamente ejemplos que roban hashes (con la excepción de SQLi), pero ejemplos de cómo pueden funcionar las vulnerabilidades. El atacante usaría las vulnerabilidades a continuación para comprometer aún más un sistema.

  1. inyección SQL

    Ejemplo:
    a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--

    También puedes usar sp_msforeachdb , así:

    a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

    El -- está allí para comentar partes de la declaración SQL que pueden interferir con su inyección. Estos son solo ejemplos muy básicos. Realmente depende del formato de la consulta.

  2. Inyección del sistema operativo . %código%
  3. Inyección LDAP . ; cat /etc/passwd; rm -rf /* , *
  4. Referencia de objetos directa insegura que conduce a la vulnerabilidad de inclusión de archivos locales / remotos .

    (cn = *)(|(password =*))

    /etc/passwd%00 es un "terminador nulo" que se usa para evitar que algo venga después de él, por lo que no intentas incluir algo que no existe, por ejemplo: %00 . También podría ser /etc/passwd.txt , \x000 , \z , \u0000 , %code% o %code% dependiendo del idioma que esté usando.

  5. Hackeando a un desarrollador / usuario con acceso a las bases de datos.
  6. Explotación del servidor de base de datos o servidor web a través de otros medios.
respondido por el Mark Buffalo 23.08.2016 - 16:39
fuente
9

Una adición a Mark Buffalo:
7. El ataque del hombre en el medio. Ver el tráfico no cifrado a menudo puede revelar un hash de contraseña. En el caso de pasar el hash, los sistemas confiarán en el hash y la contraseña y permitirán que un atacante simplemente copie el hash sin romperlo.

    
respondido por el MikeP 23.08.2016 - 19:29
fuente
5
  

La única computadora verdaderamente segura es aquella que está aislada de Internet, apagada, desenchufada, enterrada en un bunker de 100 pies bajo tierra, con guardias armados en la única entrada. Incluso entonces, lo revisaría de vez en cuando.

Hashing las contraseñas es parte de lo que se conoce como "seguridad en profundidad". Usted tiene razón en que, en un mundo ideal, no cometería ningún error que les daría a los atacantes acceso a esos datos, por lo que en teoría no importaría si fueran contraseñas o hashes de texto simple. En un mundo real, ocurren intrusiones, y es muy difícil predecir cómo y dónde ocurrirán. La idea de la seguridad en profundidad es hacer que, en teoría, incluso si un atacante compromete su sistema de alguna manera, haya realizado esfuerzos para mitigar el daño.

En el mundo real, existe una necesidad natural de acceder a los hashes de forma regular. Cada vez que un usuario inicia sesión, necesita la capacidad de acceder a ellos. En consecuencia, casi siempre son accesibles para cualquier aplicación que esté realizando la autenticación. Si alguien compromete su solicitud, es posible que puedan leer datos que no debían leer.

Las formas en que ocurren estos ataques son infinitas. Puede tener ataques de inyección SQL si no pudo desinfectar sus entradas. Podría tener una saturación del búfer, que le da al atacante la capacidad de ejecutar su propio código. Podría tener un error de permisos, haciendo que un archivo sea legible por personas cuando no debería haberlo hecho. ¡El atacante puede obtener una de sus cintas de copia de seguridad debido a un mal manejo por parte de su servicio de copia de seguridad!

Todos estos ataques le dan a un atacante un punto de apoyo en su computadora, pero no siempre resultan en una interrupción completa. Es posible que haya puesto chroot en su servidor SQL, de modo que el proceso del servidor SQL literalmente no pueda ver el resto del equipo. Sin embargo, en tales situaciones, la información de inicio de sesión que necesitan los usuarios debe estar al alcance del servidor SQL, o no tiene ningún valor. Por lo tanto, la información de inicio de sesión suele estar comprometida antes de que ocurran otros compromisos más infames.

Al codificar las contraseñas, disminuye su valor. Un hash no es útil para propósitos de inicio de sesión. Necesitan tener la contraseña que hash a ese valor. Pueden o no pueden pagar el costo de romper el hash. En el mejor de los mundos, nunca tuvo que preocuparse por esto en primer lugar, pero si se suscribe al enfoque de seguridad en profundidad, se asegura de que incluso una intrusión exitosa no comprometa todos sus datos.

    
respondido por el Cort Ammon 23.08.2016 - 23:45
fuente
2

Algunas instalaciones un * x / linux en red de la vieja escuela seguirán utilizando el servicio NIS / YP para la autenticación administrada centralmente. NIS publica de manera efectiva las contraseñas con hash en la red para que cada estación de trabajo autentique a los usuarios.

    
respondido por el rackandboneman 24.08.2016 - 11:53
fuente

Lea otras preguntas en las etiquetas