mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 22:52:06 +00:00
68 lines
9.2 KiB
Markdown
68 lines
9.2 KiB
Markdown
|
<details>
|
||
|
|
|
||
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
|
|
||
|
|
- ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||
|
|
|
||
|
|
- Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
|
|
|
||
|
|
- Obtén la [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||
|
|
|
||
|
|
- **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||
|
|
|
||
|
|
- **Comparte tus trucos de hacking enviando PRs al [repositorio de hacktricks](https://github.com/carlospolop/hacktricks) y al [repositorio de hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
|
||
|
|
|
||
|
|
</details>
|
||
|
|
|
||
|
|
|
||
|
|
PAM es una colección de módulos que esencialmente forman una barrera entre un servicio en tu sistema y el usuario del servicio. Los módulos pueden tener propósitos muy variados, desde prohibir el inicio de sesión a usuarios de un grupo UNIX en particular \(o netgroup, o subnet…\), hasta implementar límites de recursos para que tu grupo de "investigación" no pueda acaparar los recursos del sistema.
|
||
|
|
|
||
|
|
# Archivos de configuración
|
||
|
|
|
||
|
|
Solaris y otros sistemas UNIX comerciales tienen un modelo de configuración ligeramente diferente, centrado en un único archivo, **`/etc/pam.conf`**. En la mayoría de los sistemas Linux, estos archivos de configuración se encuentran en **`/etc/pam.d`**, y se nombran según el servicio - por ejemplo, el archivo de configuración de "login" se llama **`/etc/pam.d/login`**. Echemos un vistazo rápido a una versión de ese archivo:
|
||
|
|
```text
|
||
|
|
auth required /lib/security/pam_securetty.so
|
||
|
|
auth required /lib/security/pam_nologin.so
|
||
|
|
auth sufficient /lib/security/pam_ldap.so
|
||
|
|
auth required /lib/security/pam_unix_auth.so try_first_pass
|
||
|
|
account sufficient /lib/security/pam_ldap.so
|
||
|
|
account required /lib/security/pam_unix_acct.so
|
||
|
|
password required /lib/security/pam_cracklib.so
|
||
|
|
password required /lib/security/pam_ldap.so
|
||
|
|
password required /lib/security/pam_pwdb.so use_first_pass
|
||
|
|
session required /lib/security/pam_unix_session.so
|
||
|
|
```
|
||
|
|
## **Reinos de gestión de PAM**
|
||
|
|
|
||
|
|
La columna más a la izquierda contiene cuatro palabras únicas, que representan cuatro reinos de gestión de PAM: **auth**, **account**, **password** y **session**. Aunque hay muchos módulos que admiten más de uno de estos reinos \(de hecho, pam\_unix los admite todos\), otros, como pam\_cracklib, por ejemplo, solo son adecuados para uno \(en el caso de pam\_cracklib, la facilidad de 'password'\).
|
||
|
|
|
||
|
|
* **auth**: El reino 'auth' \(lo llamo reino - los documentos se refieren a él como un 'grupo de gestión' o 'facilidad'\) es responsable de verificar que el usuario es quien dice ser. Los módulos que se pueden listar en esta área **generalmente** admiten **solicitar una contraseña**.
|
||
|
|
* **account**: Esta área es responsable de una amplia variedad de posibles funcionalidades de **verificación de cuenta**. Hay muchos módulos disponibles para esta facilidad. Las restricciones para el uso de un servicio basado en **verificar la pertenencia a un grupo**, la hora del día, si una cuenta de usuario es local o remota, etc., generalmente se hacen cumplir mediante módulos que admiten esta facilidad.
|
||
|
|
* **password**: Los módulos en esta área son responsables de cualquier funcionalidad necesaria en el curso de **actualizar contraseñas** para un servicio determinado. La mayoría de las veces, esta sección es bastante "normal", simplemente llamando a un módulo que **solicitará una contraseña actual**, y, suponiendo que eso sea exitoso, le pedirá una nueva. También se pueden agregar otros módulos para realizar **comprobaciones de complejidad de contraseñas** o de diccionario, como los realizados por los módulos pam\_cracklib y pam\_pwcheck.
|
||
|
|
* **session**: Los módulos en esta área realizan cualquier cantidad de cosas que suceden **durante la configuración o limpieza de un servicio** para un usuario determinado. Esto puede incluir cualquier cantidad de cosas; lanzar un script de inicialización en todo el sistema, realizar un registro especial, **montar el directorio de inicio del usuario**, o establecer límites de recursos.
|
||
|
|
|
||
|
|
## **Controles de módulo PAM**
|
||
|
|
|
||
|
|
La **columna central** contiene una palabra clave que esencialmente determina **qué debe hacer PAM si el módulo tiene éxito o falla**. Estas palabras clave se llaman 'controles' en el lenguaje de PAM. En el 90% de los casos, se puede usar una de las palabras clave comunes \(**requisite**, **required**, **sufficient** u **optional**\). Sin embargo, esto es solo la punta del iceberg en términos de liberar la flexibilidad y el poder de PAM.
|
||
|
|
|
||
|
|
* **required**: Si un módulo 'required' devuelve un estado que **no es 'éxito'**, la **operación siempre fallará**, pero solo después de que se invoquen los **módulos debajo de él**. Esto parece sin sentido a primera vista, supongo, pero sirve para **actuar siempre de la misma manera desde el punto de vista del usuario** que intenta utilizar el servicio. El efecto neto es que se vuelve **imposible** para un posible atacante **determinar qué módulo causó el fallo**.
|
||
|
|
* **requisite**: Si un módulo 'requisite' falla, la **operación no solo falla**, sino que la operación se **termina inmediatamente** con un fallo sin invocar ningún otro módulo.
|
||
|
|
* **sufficient**: Si un módulo **suficiente tiene éxito**, es suficiente para satisfacer los requisitos de los módulos suficientes en ese reino para el uso del servicio, y **los módulos debajo de él que también se enumeran como 'suficientes' no se invocan**. **Si falla, la operación falla a menos que un módulo invocado después de que tenga éxito**.
|
||
|
|
* **optional**: Un módulo 'opcional', según la página del manual pam\(8\), **solo hará que una operación falle si es el único módulo en la pila para esa facilidad**.
|
||
|
|
|
||
|
|
## Ejemplo
|
||
|
|
|
||
|
|
En nuestro archivo de ejemplo, tenemos cuatro módulos apilados para el reino auth:
|
||
|
|
```text
|
||
|
|
auth required /lib/security/pam_securetty.so
|
||
|
|
auth required /lib/security/pam_env.so
|
||
|
|
auth sufficient /lib/security/pam_ldap.so
|
||
|
|
auth required /lib/security/pam_unix.so try_first_pass
|
||
|
|
```
|
||
|
|
Como los módulos se invocan en orden, esto es lo que sucederá:
|
||
|
|
|
||
|
|
1. El módulo '**pam_securetty**' verificará su archivo de configuración, **`/etc/securetty`**, y verá si el terminal que se está utilizando para este inicio de sesión está en la lista del archivo. Si **no lo está, no se permitirán los inicios de sesión de root**. Si intentas iniciar sesión como root en un terminal 'malo', este módulo fallará. Como es 'requerido', aún invocará todos los módulos en la pila. Sin embargo, incluso si todos ellos tienen éxito, el inicio de sesión fallará. Es interesante destacar que si el módulo se enumerara como 'requisito', la operación terminaría con un fallo inmediatamente, sin invocar ninguno de los otros módulos, sin importar cuál sea su estado.
|
||
|
|
2. El módulo '**pam_env**' **establecerá variables de entorno** en función de lo que el administrador haya configurado en /etc/security/pam_env.conf. En una configuración predeterminada de Redhat 9, Fedora Core 1 y Mandrake 9.2, el archivo de configuración para este módulo en realidad no establece ninguna variable. Un buen uso para esto podría ser establecer automáticamente una variable de entorno DISPLAY para un usuario que inicie sesión a través de SSH para que no tenga que establecerla él mismo si desea enviar un 'xterm' de vuelta a su escritorio remoto (aunque esto puede ser manejado automáticamente por OpenSSH).
|
||
|
|
3. El módulo '**pam_ldap**' **solicitará** al usuario una **contraseña** y luego verificará el directorio ldap indicado en **`/etc/ldap.conf`** para autenticar al usuario. Si esto falla, la operación aún puede tener éxito si 'pam_unix' tiene éxito en autenticar al usuario. Si pam_ldap tiene éxito, 'pam_unix' no se invocará.
|
||
|
|
4. El módulo '**pam_unix**', en este caso, **no solicitará al usuario una contraseña**. El argumento 'try_first_pass' le indicará al módulo que **use la contraseña que le dio el módulo anterior** (en este caso, pam_ldap). Intentará autenticar al usuario utilizando las llamadas al sistema estándar getpw\*. Si pam_unix falla y pam_ldap ha fallado, la operación fallará. Si pam_ldap falla pero pam_unix tiene éxito, la operación tendrá éxito (¡esto es extremadamente útil en casos en los que root no está en el directorio ldap, pero aún está en el archivo local /etc/passwd!).
|