¿Por qué todos están tan preocupados por etc / passwd?

Aquí está el contenido de mi máquina vagabunda de este archivo en particular:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/us$
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:100:103::/home/syslog:/bin/false

¿Alguien podría explicarme por qué es malo si un malvado podría obtener este archivo de mi servidor de producción?

security passwd-file

— chico divertido
fuente

En los viejos tiempos, contenía las contraseñas cifradas para cada usuario, donde ahora está: x:. Si lo obtuviste (lo cual fue fácil ya que es legible por todos, por lo que solo necesitas un inicio de sesión), podrías descifrar las contraseñas por fuerza bruta. Ahora están almacenados en / etc / shadow, que no todos pueden leer, por lo que es menos probable que "salgan", pero que tendrían el mismo problema si lo hicieran.

— Mark Smith

Por un lado, puedo decir que tiene un servidor web en esta máquina. En combinación con su dirección IP, podría ser pirateable>: - D

— Rinzwind

@ MarkSmith Contenía contraseñas cifradas cuando? AFAIK comenzó la vida como contraseñas hash. Ciertamente desde que usé Unix por primera vez en 1982.

— user207421

@funguy: usualmente los servidores web usan el usuario www-data. Ubuntu y probablemente Debian usaron a este usuario como el usuario predeterminado de Apache.

— Mentira Ryan

@funguy www-data es el usuario predeterminado de apache. Hay más: uucp es unix a unix copy; eso significa que copia archivos entre sistemas. Y "irc" y "mosquitos" también son fáciles de detectar.

— Rinzwind

Respuestas:

El punto clave es que los Pentesters / white-hats / ethics hackers, así como el black-hat /etc/passwd como objetivo proof of concept, como prueba de la posibilidad de obtener acceso a un sistema.

Técnicamente /etc/passwdno es tan aterrador. En el pasado, solía almacenar datos privados, contraseñas obviamente, pero a partir de hoy debería preocuparse más /etc/shadow: la mayoría de los sistemas Linux en la actualidad usan un shadowconjunto de utilidades para mantener una contraseña codificada y salada /etc/shadow, que a diferencia de /etc/passwdno es el mundo -legible. (a menos que use el pwunconvcomando, que en realidad mueve las contraseñas hash de nuevo a `/ etc / passwd).

La única información más o menos sensible son los nombres de usuario. Si tiene sshdo telneten el servidor y un nombre de usuario con contraseña débil, existe la posibilidad de un ataque de fuerza bruta.

Por cierto, tu misma pregunta ya se ha hecho antes . Aquí me limité a repetir algunos de los conceptos mencionados allí.

Pequeña adición: esto es un poco exagerado, pero he notado que tiene bashcomo shell raíz. Ahora, supongamos que tiene un usuario en el sistema que tiene bashcomo caparazón, aún peor: ese usuario es sudoer. Ahora, si bash está desactualizado o sin parchear, un atacante podría tratar de explotar la vulnerabilidad Shellshock para robar datos o ejecutar una bomba tenedor que derribe su sistema temporalmente. Entonces sí, técnicamente /etc/passwdno es un gran problema, pero le da al atacante una idea de parte de la información sobre qué intentar

Edición adicional, 18/11/2016

Después de haber usado un servidor Ubuntu en Digital Ocean durante un tiempo, me llamó la atención que la mayoría de los ataques de fuerza bruta contra mi servidor se llevaron a cabo para el rootusuario: el 99% de las entradas para la contraseña fallida /var/log/auth.logfueron para root. /etc/password, como mencioné antes, el atacante observa la lista de usuarios, y no solo los usuarios del sistema, sino también los usuarios humanos, lo que significa más lugares potenciales para el ataque. Recordemos que no todos los usuarios son conscientes de la seguridad y no siempre crean una contraseña segura, por lo que la apuesta de un atacante por error humano o exceso de confianza tiene una probabilidad bastante alta de ser un premio gordo.

— Sergiy Kolodyazhnyy
fuente

+1, gran respuesta. Además de esto, me gustaría decir también que, en general, la información es poder; Dejando de lado el infame Shellshock, uno podría reunir, por ejemplo, información sobre los procesos en ejecución, que también podrían ser explotados; por ejemplo, en la máquina de OP, Apache se está ejecutando, y ese es otro agujero potencial sin cubrir

— kos

Hmm ... ¿Entonces sugeriría cambiar los nombres de usuario predeterminados para confundir a un atacante?

— Freedo

@ Libertad Eso no ayuda. Las identificaciones de usuario y grupo permanecen iguales si cambia el inicio de sesión. Por ejemplo, aquí está mi testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Después de ejecutar sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , la entrada tiene otro nombre de usuario, pero GID y UID son los mismos: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Si la contraseña no se modifica, el atacante puede adivinar y aún así descifrar el sistema. Requerir que la contraseña caduque y se cambie de vez en cuando es un mejor enfoque, pero tampoco es a prueba de balas.

— Sergiy Kolodyazhnyy

Cambiar los nombres de usuario predeterminados ES útil para aquellas cuentas que tienen inicios de sesión SSH (u otros inicios de sesión remotos). Por lo tanto, está cambiando los puertos predeterminados para esos inicios de sesión, por supuesto. Cualquier cosa que le permita mantener sus registros libres de miles de millones de escaneos aleatorios por parte de script kiddies significará que puede concentrarse en los ataques más deliberados. Si sus nombres personalizados aparecen en sus registros de inicio de sesión fallido, sabrá que es un intento serio de ingresar, en lugar de un paso en falso.

— Dewi Morgan

Para iniciar sesión en una máquina, debe conocer tanto el nombre de usuario como la contraseña.

/etc/passwd proporciona información sobre los usuarios que le brinda la mitad de la información que necesita y solía incluir un hash de su contraseña.

Un hash es algo calculado a partir de su contraseña. Es difícil encontrar una contraseña de un hash pero no al revés. Si tiene ambos, puede intentar intentos de fuerza bruta para encontrar la contraseña fuera de línea y luego solo intente conectarse a la computadora una vez que la haya encontrado.

Hoy la seguridad se mejora porque los hashes se almacenan en un archivo diferente /etc/shadowque, de manera predeterminada, la mayoría de los usuarios no pueden leer.

Pero, si tuviera acceso a ambos /etc/passwdy /etc/shadowprobablemente podría encontrar su contraseña usando un ataque de 'diccionario' de fuerza bruta. Como puedo hacer esto localmente en mi máquina, no notaría muchos intentos fallidos de encontrar su contraseña y solo necesitaría conectarme a su máquina nuevamente una vez que supiera la contraseña. Entonces soy libre de hacer lo que quiera.

Hay más información aquí en Wikipedia

— Warren Hill
fuente

Siente que probablemente deberías mencionar 'tablas de arcoiris' aquí solo para dar una idea de cómo funciona ese ataque de fuerza bruta.

— Rick Chatham