Last updated
Aprenda e pratique Hacking AWS:HackTricks Treinamento AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Treinamento GCP Red Team Expert (GRTE)
A maneira mais comum de fazer login no Jenkins é com um nome de usuário ou uma senha.
Se um cookie autorizado for roubado, ele pode ser usado para acessar a sessão do usuário. O cookie geralmente é chamado de JSESSIONID.*. (Um usuário pode encerrar todas as suas sessões, mas precisaria descobrir primeiro que um cookie foi roubado).
O Jenkins pode ser configurado usando plugins para ser acessível via SSO de terceiros.
Os usuários podem gerar tokens para dar acesso a aplicativos para se passar por eles via CLI ou REST API.
Este componente fornece um servidor SSH embutido para o Jenkins. É uma interface alternativa para o Jenkins CLI, e os comandos podem ser invocados dessa forma usando qualquer cliente SSH. (Das docs)
Em /configureSecurity é possível configurar o método de autorização do Jenkins. Existem várias opções:
Qualquer um pode fazer qualquer coisa: Até o acesso anônimo pode administrar o servidor.
Modo legado: Igual ao Jenkins <1.164. Se você tiver o papel "admin", terá controle total sobre o sistema, e caso contrário (incluindo usuários anônimos) você terá acesso somente leitura.
Usuários logados podem fazer qualquer coisa: Neste modo, cada usuário logado tem controle total do Jenkins. O único usuário que não terá controle total é o usuário anônimo, que só terá acesso de leitura.
Segurança baseada em matriz: 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/papel. Isso inclui um usuário especial 'anônimo', que representa usuários não autenticados, bem como 'autenticado', que representa todos os usuários autenticados.
Estratégia de Autorização Baseada em Projeto: Este modo é uma extensão da "segurança baseada em matriz" que permite que ACLs adicionais sejam definidas para cada projeto separadamente.
Estratégia Baseada em Papéis: Permite definir autorizações usando uma estratégia baseada em papéis. Gerencie os papéis em /role-strategy.
Em /configureSecurity é possível configurar o reino de segurança. Por padrão, o Jenkins inclui suporte para alguns Reinos de Segurança diferentes:
Delegar ao contêiner de servlet: Para delegar a autenticação a um contêiner de servlet que executa o controlador Jenkins, como Jetty.
Banco de dados de usuários próprio do Jenkins: Use o próprio armazenamento de dados de usuários embutido do Jenkins para autenticação em vez de delegar a um sistema externo. Isso é habilitado por padrão.
LDAP: Delegar toda a autenticação a um servidor LDAP configurado, incluindo usuários e grupos.
Banco de dados de usuários/grupos Unix: Delegar a autenticação ao banco de dados de usuários do sistema operacional Unix subjacente no controlador Jenkins. Este modo também permitirá a reutilização de grupos Unix para autorização.
Plugins podem fornecer reinos de segurança adicionais que podem ser úteis para incorporar o Jenkins em sistemas de identidade existentes, como:
Definições das docs:
Nós são as máquinas nas quais os agentes de construção são executados. O Jenkins monitora cada nó conectado em relação ao espaço em disco, espaço temporário livre, swap livre, tempo/sincronização do relógio e tempo de resposta. Um nó é desconectado se qualquer um desses valores ultrapassar o limite configurado.
Agentes gerenciam a execução de tarefas em nome do controlador Jenkins usando executores. Um agente pode usar qualquer sistema operacional que suporte Java. Ferramentas necessárias para construções e testes são instaladas no nó onde o agente é executado; elas podem ser instaladas diretamente ou em um contêiner (Docker ou Kubernetes). Cada agente é 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 agente. O número de executores em um nó define o número de tarefas concorrentes que podem ser executadas nesse nó ao mesmo tempo. Em outras palavras, isso determina o número de stages de Pipeline concorrentes que podem ser executados nesse nó ao mesmo tempo.
Definição das docs: O Jenkins usa AES para criptografar e proteger segredos, credenciais e suas respectivas chaves de criptografia. Essas chaves de criptografia são armazenadas em $JENKINS_HOME/secrets/ junto com a chave mestre usada para proteger essas chaves. Este diretório deve ser configurado para que apenas o usuário do sistema operacional sob o qual o controlador Jenkins está sendo executado tenha acesso de leitura e gravação a este diretório (ou seja, um valor chmod de 0700 ou usando atributos de arquivo apropriados). A chave mestre (às vezes referida como "chave de criptografia" em jargão criptográfico) é armazenada _não criptografada_ no sistema de arquivos do controlador Jenkins 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, seja através da API Secret para criptografar dados secretos genéricos ou através da API de credenciais. Para os curiosos sobre criptografia, o Jenkins usa AES no modo de encadeamento de bloco de cifra (CBC) com preenchimento PKCS#5 e IVs aleatórios para criptografar instâncias de CryptoConfidentialKey que são armazenadas em $JENKINS_HOME/secrets/ com um nome de arquivo correspondente ao seu id de CryptoConfidentialKey. IDs de chave comuns incluem:
hudson.util.Secret: usado para segredos genéricos;
com.cloudbees.plugins.credentials.SecretBytes.KEY: usado para alguns tipos de credenciais;
jenkins.model.Jenkins.crumbSalt: usado pelo mecanismo de proteção CSRF; e
As credenciais podem ser escopadas para provedores globais (/credentials/) que podem ser acessados por qualquer projeto configurado, ou podem ser escopadas para projetos específicos (/job/<project-name>/configure) e, portanto, acessíveis apenas a partir do projeto específico.
De acordo com as docs: As credenciais que estão em escopo são disponibilizadas para o pipeline sem limitações. Para evitar exposição acidental no log de construção, as credenciais são mascaradas da saída regular, de modo que uma invocação de env (Linux) ou set (Windows), ou programas que imprimem seu ambiente ou parâmetros não as revelariam no log de construção para usuários que não teriam acesso às credenciais.
É por isso que, para exfiltrar as credenciais, um atacante precisa, por exemplo, codificá-las em base64.
Aprenda e pratique Hacking AWS:HackTricks Treinamento AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Treinamento GCP Red Team Expert (GRTE)
