En los sitios web de exploits, veo analistas de seguridad y piratas informáticos dirigidos al archivo / etc / passwd cuando muestro la prueba de concepto.
Si tiene una vulnerabilidad de inclusión de archivos locales o una ruta transversal en su servidor y los piratas informáticos pueden acceder (ver, leer, pero NO editar) el archivo / etc / passwd, ¿cuáles son las repercusiones de esto? ¿No están todas las contraseñas ofuscadas en este archivo por diseño?
La única real repercusión es el reconocimiento: el atacante puede aprender los nombres de inicio de sesión y los campos de gecos (que a veces ayudan a adivinar contraseñas) del archivo /etc/passwd .
Una razón para esto es que, hace 20 años, la mayoría de las variantes de Unix cambiaron de mantener las contraseñas con hash en el archivo /etc/passwd y las movieron a /etc/shadow . La razón de esto fue que /etc/passwd necesitaba ser legible en todo el mundo para que funcionaran herramientas como 'finger' e 'ident'. Una vez que las contraseñas fueron segregadas en /etc/shadow , ese archivo se hizo legible solo por la raíz.
Dicho esto, /etc/passwd sigue siendo una "bandera" popular para los analistas de seguridad y hackers porque es un archivo tradicional "hey, tengo lo que no debería". Si puedes leer eso, puedes leer otras cosas en / etc también, algunas de las cuales pueden ser útiles para un atacante. Pero es más difícil probar (por ejemplo) /etc/yum.conf si no sabe si yum está en el sistema; /etc/passwd siempre está ahí y es una prueba confiable de si el acceso funcionó.
Dicho de otra manera, la implícita de obtener /etc/passwd es que el atacante ha eludido los controles y puede obtener archivos de lectura arbitrarios, lo que significa "¡Yo gano!" *
* No hay garantía real de ganar, expresa o implícita
Mientras @gowenfawr alcanza los puntos principales, tengo algunos para agregar:
La mayoría de los sistemas, pero no todos , ocultan las contraseñas reales en /etc/shadow . Para ver si su sistema es vulnerable, verifique una cuenta de usuario real. Si parece que
stighemmer:x:...
Entonces tus contraseñas son seguras.
Si parece
stighemmer:kjsaashgdkwqvbm:...
Entonces tus contraseñas son NO seguras.
Sí, la contraseña se confunde con una función hash de una sola vía, pero eso no es suficiente. Tener este archivo le permite al pirata informático verificar si un usuario determinado tiene una contraseña determinada sin intentar iniciar sesión.
En 1970, este control fue lento y las cosas eran razonablemente seguras. Hoy, un hacker puede verificar millones de contraseñas por segundo. Si uno de sus usuarios tiene una contraseña que se puede adivinar, la cuenta de ese usuario será hackeada. Y el límite de lo que es "adivinable" se empuja con cada generación de procesadores.
Ahora ha comprobado y ha encontrado que sus contraseñas están almacenadas de forma segura en /etc/shadow . Bien, problema resuelto.
No del todo. /etc/passwd contiene más información.
Contiene el nombre completo de cada usuario. Esto es muy útil para ataques de ingeniería social.
Contiene una lista de usuarios del sistema, que indica qué software está instalado.
Por lo tanto, recibo un correo electrónico que dice "Hola Stig, he olvidado la contraseña de postgres. ¿Me lo recuerdas? Firmado, otro usuario real". Como mi cliente de correo electrónico útil no muestra la dirección de correo electrónico completa, no me daré cuenta de que este correo electrónico proviene de un país remoto. Yo respondo: "Es 'S3CR37'". Vaya, la base de datos de la empresa acaba de ser hackeada.
Por supuesto, esta no es la única forma en que se exponen los nombres completos, de todos modos, debe enseñar a los usuarios los ataques de ingeniería social.
A menos que no esté utilizando contraseñas ocultas, el acceso a /etc/passwd no es el riesgo masivo que implicaría el nombre de archivo (y si no está utilizando contraseñas ocultas en la actualidad) tienes un problema).
Los primeros sistemas Unix realmente almacenaron contraseñas en /etc/passwd , por lo que el archivo se llama así . También almacenó algunos otros aspectos de los metadatos del usuario, como el directorio de inicio del usuario, el shell, etc. En retrospectiva, esta no fue la mejor decisión de diseño que se haya tomado, porque significaba que los programas que usaban estos metadatos debían poder leer /etc/passwd para obtener esos datos.
Las contraseñas en /etc/passwd se cifraron usando los algoritmos de la época, pero incluir las contraseñas cifradas era todavía un riesgo de exposición innecesario , por lo que se implementaron contraseñas ocultas para resolverlo. El formato de /etc/passwd no pudo cambiar, por razones históricas, pero los sistemas modernos solo ponen un marcador de posición allí ( x es común). La información real relacionada con la contraseña (los hashes reales, la antigüedad de la contraseña, etc.) se almacenan en otro archivo, /etc/shadow , que solo la raíz puede leer.
Esto no quiere decir que el acceso a /etc/passwd sea completamente inofensivo . Todavía produce una lista de nombres de usuario, y aunque eso es teóricamente inofensivo (ya que se supone que los nombres de usuario no son secretos), puede ser deprimente saber cuánta gente usa su nombre de usuario como contraseña. Ocurre con menos frecuencia en este día y edad, pero todavía sucede con la frecuencia suficiente para que valga la pena intentarlo.
Además, el campo GECOS en /etc/passwd a menudo contiene metadatos como los nombres reales de los usuarios. Esto puede ser útil para realizar conjeturas rápidas en sí mismo o para realizar búsquedas detalladas que puedan ofrecer estimaciones más probables. Sin embargo, se trata de cosas bastante sofisticadas, que van mucho más allá (y posiblemente ni siquiera requieren) el acceso a /etc/passwd en sí mismo
Al realizar evaluaciones de vulnerabilidad para los clientes, uso /etc/passwd como "hey, tengo LFI en esta aplicación y deberías estar al tanto". Es un archivo simple y conocido que generalmente tiene suficientes permisos en el sistema de archivos para mostrar que puedo leer archivos. Dado que se trata de una evaluación de la vulnerabilidad, a mí y al cliente solo nos preocupamos por la vulnerabilidad que está presente, la prueba proporcionada y la orientación sobre cómo resolver el problema.
Cuando estoy realizando un pentest para un cliente, este archivo, aunque normalmente no contiene contraseñas, me da mucha información. De ahí, tengo nombres de inicio de sesión para comenzar a adivinar las contraseñas y puedo usar el LFI existente para luego intentar leer los archivos del usuario.
Este mismo razonamiento se aplica a la prueba de conceptos XSS y a <script>alert(1)</script> . No es lo peor que puedes hacer con XSS, pero es una prueba de que yo, como atacante, tengo la capacidad de ejecutar JavaScript bajo mi control.
Un atacante puede ver Usuarios creados manualmente (UID > 500 o > 1000 en la mayoría de los linuxes que he tocado hasta ahora) y también ver shells asignados (/ bin / ba (sh)) para saber en qué pueden trabajar los usuarios. Servicios y / o aplicaciones web disponibles en la máquina. ¡SSH no es el único objetivo!
Esta información no solo es útil para la fuerza bruta genérica sino también para todos los ataques que puedan implicar el conocimiento de un nombre de usuario válido (ser creativo).
Como se mencionó anteriormente: cuando un atacante puede leer / etc / passwd, también puede leer mucho más en el sistema y determinar sistemáticamente si hay formas de obtener shells inversos y escalada de privilegios locales.
Te recomiendo que leas algunas guías privesc de linux (mubix & g0tmilk para empezar) y pongas en práctica algunos vms vulnerables para algún entrenamiento práctico sobre privesc (vulnhub.com / kioptrix es un buen punto de partida).
Lea otras preguntas en las etiquetas vulnerability directory-traversal