Informações Básicas do Jenkins

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Acesso

Nome de usuário + Senha

A forma mais comum de login no Jenkins é com nome de usuário ou senha

Se um cookie autorizado for roubado, ele pode ser usado para acessar a sessão do usuário. O cookie geralmente se chama JSESSIONID.*. (Um usuário pode terminar todas as suas sessões, mas ele precisaria descobrir primeiro que um cookie foi roubado).

SSO/Plugins

O Jenkins pode ser configurado usando plugins para ser acessível via third party SSO.

Tokens

Usuários podem gerar tokens para dar acesso a aplicações para se fazerem passar por eles via CLI ou REST API.

SSH Keys

Este componente fornece um servidor SSH embutido para o Jenkins. É uma interface alternativa para o Jenkins CLI, e comandos podem ser invocados dessa forma usando qualquer cliente SSH. (Conforme os docs)

Autorização

Em /configureSecurity é possível configurar o método de autorização do Jenkins. Existem várias opções:

  • Anyone can do anything: Até o acesso anonymous pode administrar o servidor
  • Legacy mode: Igual ao Jenkins <1.164. Se você tem a role “admin”, será concedido controle total sobre o sistema, e caso contrário (incluindo usuários anonymous) terá acesso de leitura.
  • Logged-in users can do anything: Neste modo, todo usuário logado obtém controle total do Jenkins. O único usuário que não terá controle total é o anonymous, que recebe apenas acesso de leitura.
  • Matrix-based security: Você pode configurar quem pode fazer o quê em uma tabela. Cada coluna representa uma permissão. Cada linha representa um usuário ou um grupo/role. Isto inclui um usuário especial ‘anonymous’, que representa usuários não autenticados, assim como ‘authenticated’, que representa todos os usuários autenticados.

  • Project-based Matrix Authorization Strategy: Este modo é uma extensão da “Matrix-based security” que permite que matrizes ACL adicionais sejam definidas para cada projeto separadamente.
  • Role-Based Strategy: Permite definir autorizações usando uma estratégia baseada em roles. Gerencie as roles em /role-strategy.

Domínio de Segurança

Em /configureSecurity é possível configurar o security realm. Por padrão o Jenkins inclui suporte para alguns Security Realms diferentes:

  • Delegate to servlet container: Para delegar a autenticação a um servlet container que esteja executando o Jenkins controller, como Jetty.
  • Jenkins’ own user database: Use o próprio repositório de usuários embutido do Jenkins para autenticação em vez de delegar a um sistema externo. Isto vem ativado por padrão.
  • LDAP: Delegue toda a autenticação a um servidor LDAP configurado, incluindo tanto usuários quanto grupos.
  • Unix user/group database: Delegates the authentication to the underlying Unix OS-level user database no controller Jenkins. Este modo também permitirá reuso de grupos Unix para autorização.

Plugins podem fornecer realms de segurança adicionais que podem ser úteis para incorporar o Jenkins em sistemas de identidade existentes, tais como:

Nós, Agentes & Executors do Jenkins

Definitions from the docs:

Nodes são as máquinas nas quais os build agents rodam. O Jenkins monitora cada node anexado por espaço em disco, espaço temp livre, swap livre, tempo do relógio/sincronização e tempo de resposta. Um node é colocado offline se qualquer um desses valores sair dos limites configurados.

Agents gerenciam a execução de tarefas em nome do Jenkins controller usando executors. Um agent pode usar qualquer sistema operacional que suporte Java. Ferramentas requeridas para builds e testes são instaladas no node onde o agent roda; elas podem ser instaladas diretamente ou em um container (Docker ou Kubernetes). Cada agent é efetivamente um processo com seu próprio PID na máquina host.

Um executor é um slot para execução de tarefas; efetivamente, é uma thread no agent. O número de executors em um node define o número de tarefas concorrentes que podem ser executadas naquele node ao mesmo tempo. Em outras palavras, isto determina o número de Pipeline stages concorrentes que podem executar naquele node ao mesmo tempo.

Segredos do Jenkins

Criptografia de Segredos e Credenciais

Definition from the docs: O Jenkins usa AES para criptografar e proteger secrets, credenciais e suas respectivas chaves de criptografia. Essas chaves de criptografia são armazenadas em $JENKINS_HOME/secrets/ junto com a master key usada para proteger tais chaves. Este diretório deve ser configurado para que somente o usuário do sistema operacional com o qual o Jenkins controller está rodando tenha acesso de leitura e escrita a este diretório (por exemplo, um valor chmod de 0700 ou usando atributos de arquivo apropriados). A master key (às vezes referida como “key encryption key” em jargão cripto) é stored _unencrypted_ no filesystem do Jenkins controller em $JENKINS_HOME/secrets/master.key o que não protege contra atacantes com acesso direto a esse arquivo. A maioria dos usuários e desenvolvedores usará essas chaves de criptografia indiretamente via a API [Secret] para criptografar dados secretos genéricos ou através da credentials API. Para os cripto-curiosos, o Jenkins usa AES em modo CBC com padding PKCS#5 e IVs randômicos para criptografar instâncias de [CryptoConfidentialKey] que são armazenadas em $JENKINS_HOME/secrets/ com um nome de arquivo correspondente ao id de seu CryptoConfidentialKey. IDs comuns de chave incluem:

  • hudson.util.Secret: usado para secrets genéricos;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: usado por alguns tipos de credenciais;
  • jenkins.model.Jenkins.crumbSalt: usado pelo CSRF protection mechanism; e

Acesso a Credenciais

As credenciais podem ser escopadas a provedores globais (/credentials/) que podem ser acessados por qualquer projeto configurado, ou podem ser escopadas a projetos específicos (/job/<project-name>/configure) e, portanto, apenas acessíveis a partir do projeto específico.

De acordo com the docs: Credenciais que estão no escopo são disponibilizadas para o pipeline sem limitação. Para prevenir exposição acidental no log do build, credenciais são mascaradas na saída regular, então uma invocação de env (Linux) ou set (Windows), ou programas que imprimem seu ambiente ou parâmetros não as revelariam no log do build para usuários que de outra forma não teriam acesso às credenciais.

That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.

Segredos em configs de plugin/job no disco

Do not assume secrets are only in credentials.xml. Muitos plugins persistem secrets em seu próprio XML global sob $JENKINS_HOME/*.xml ou em por-job $JENKINS_HOME/jobs/<JOB>/config.xml, às vezes até em plaintext (o mascaramento na UI não garante armazenamento criptografado). Se você obtiver acesso de leitura ao filesystem, enumere esses XMLs e procure por tags óbvias de secret.

# Global plugin configs
ls -l /var/lib/jenkins/*.xml
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml

# Per-job configs
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks