Integração contínua e entrega contínua (CI/CD) pipelines são a base de qualquer organização de software que construa software de uma forma “moderna”. A automação oferece grande poder, mas a maioria dos desenvolvedores não percebe a responsabilidade que isso acarreta.
Developer: Sim, nós pegamos CI/CD segurança seriamente e ter forte controle sobre os mantenedores de código, revise commits antes das mesclagens; empregos e pipelines são mantidos por funcionários seniores, eles tomam cuidado para não vazar segredos no pipelineS. E a ferramenta foi instalada por pessoal que conhece o assunto. O que pode dar errado?
Caro desenvolvedor, CI/CD sistemas são complexos. Sua ampla superfície de ataque atraiu atores malignos. É melhor ser cauteloso e nunca ter excesso de confiança.
A configuração padrão às vezes é mantida e se torna a melhor amiga dos hackers. Falhas críticas podem estar presentes em CI/CD pipeline fontes, na configuração do sistema ou em torno do processo e contexto do pipeline e como ele é acionado.
Neste post vamos nos colocar no lugar dos maus atores. Imagine que estávamos lendo as reflexões de M3M3N70 (Memento Mori?) e Fúria do Pântano em algum lugar da dark web, provavelmente em uma língua não ocidental, mas nunca perca que o mal está espalhado pelo mundo.
Nos bons e velhos tempos era tão fácil...
M3M3N70: De volta aos bons velhos tempos, nosso negócio era muuuuito fácil... Zero-days eram frutos fáceis de alcançar, os aplicativos eram abertos com vulnerabilidades fáceis de explorar e podíamos nos mover lateralmente em um piscar de olhos.
Fúria do Pântano: Fu#@Inferno! Alguns estúpidos por aí ainda, mas as coisas mudaram. Os grandes apostaram muito nessa merda de AppSec.
M3M3N70: Sim. Mas os novos tolos são os desenvolvedores. Para nós, tem sido mais fácil ir para as ferramentas que esses caras usam. O CI, em particular, é uma mina de ouro! Tokens de acesso à nuvem, SCM credenciais, senhas de banco de dados de produção, chaves privadas SSH, credenciais de outros usuários de CI... Pular das coisas chatas de desenvolvimento para a parte real era bastante trivial.
Automação para construção, teste e implantação de software com um CI/CD ferramenta frequentemente precisa passar segredos para comandos em etapas. E frequentemente eles são vazados, com consequências infames.
Pipelineprecisamos de segredos que às vezes vazam
M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.
Talvez os bons e velhos tempos tenham encontrado na história do Git um .env arquivo (o desenvolvedor esqueceu de adicioná-lo ao .gitignore):
AWS_ACCESS_KEY_ID=AKIA...AWS_SECRET_ACCESS_KEY=wJalrXUtn...AWS_REGION=us-east-1APP_FOLDER=...S3BUCKET=...
que foi usado em um fluxo de trabalho do GitHub .github/deploy.yaml que continha algo assim:
jobs:
build:
name: Automated build and deployment into AWS
runs-on: ubuntu-22.04
steps:
# Load environment from .env file
- id: dotenv
uses: falti/dotenv-action@v1.0.2
- name: Configure AWS Credentials
uses:
with:
args: --acl public-read --follow-symlinks --delete
aws-access-key-id: $
aws-secret-access-key: $
aws-region: $
# ... build steps skipped ...
- name: Upload compiled code for deployment
working-directory: $/packaged_app
run: aws s3 cp my-app.zip s3://$
- name: Deploy the app
run: aws deploy create-deployment ...
M3M3N70: uau! Essas chaves aws estavam funcionando! Testamos primeiro uma mudança inócua no aplicativo e depois adicionamos a picada, pois aqueles caras pareciam inconscientes. Bingo! Que campanha…
O malfeitor simplesmente usou as chaves da AWS para fazer upload de um aplicativo modificado com malware e, em seguida, executou o comando de implantação com essas credenciais. Os segredos vazados, juntamente com as informações contidas no pipeline. “Que campanha!” provavelmente significa que Memento causou estragos na pobre vítima.
O que o Memento nos diz aqui é que, uma vez que ocorreu um vazamento de segredo, como as chaves de acesso da AWS no exemplo, você deve revogar o segredo (girar as chaves acima) imediatamente. Há sempre um janela de exposição entre o vazamento commit e a invalidação secreta; reescrever a história do Git é difícil (mesmo o estado autoritário mais duro tentou reescrever a história, sem sucesso) e provavelmente ineficaz (nossos amigos podem ter clonado antes do repositório com o vazamento secreto commit). Gire as teclas imediatamente e ore enquanto lê os registros de atividades da conta alvo durante a janela de exposição!
Provavelmente as organizações deveriam proibir o uso de segredos de longo prazo em CI/CD pipelinese substitua-as por credenciais temporais. No exemplo anterior com chaves AWS em ações do GitHub, é mais seguro usar um Provedor OpenID Connect (OIDC) para obter credenciais de curta duração necessárias para ações.
Fúria do Pântano: Você teve muita sorte! O vazamento de scripts com chaves codificadas era uma prática comum antigamente, mesmo em buckets S3 acessíveis publicamente. Tudo o que você precisa fazer é percorrer os objetos no balde e fazer algumas buscas para encontrar coisas interessantes.
Às vezes, a área usada para implantação (um bucket AWS S3 neste exemplo) estava aberta para leitura por terceiros, devido a uma falha de configuração (que não foi detectada). O que Fúria do Pântano usado foi algo assim:
aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
aws s3 cp s3://<bucket_name>/FNAME - | \
grep '<regex_pattern>'"
O bucket provavelmente foi criado em um modelo de provisionamento que poderia ser verificado automaticamente em busca de falhas de segurança.
A configuração padrão da ferramenta era um brinquedo para nós
Para dar exemplos concretos vamos falar sobre Jenkins, uma das ferramentas de CI mais populares.
Fúria do Pântano: Você se lembra daquela caixa de seleção “Ativar segurança” no Jenkins e quantas organizações optaram por não ativá-la por questão de conveniência? E aqueles "Qualquer um pode fazer qualquer coisa”combos de permissão como padrão? E aqueles incômodos plug-ins do Jenkins, como o Plug-in GitHub OAuth? O cara que o configurou selecionou “Conceder permissões READ a todos os usuários autenticados” e “Usar permissões de repositório GitHub”, nos dando acesso a todos os seus projetos.
(Desculpas, Jenkins, por colocar você como exemplo 😉
Mantenha-se adepto (até mesmo viciado) aos princípios de segurança. Um é o Seguro por padrão princípio: os controles devem ter como padrão as configurações mais seguras possíveis. A segurança deve ser incorporada CI/CD e ferramentas pipelineé desde o início, em vez de ser uma reflexão tardia. Mas a facilidade de uso e a conveniência muitas vezes entram em conflito com a segurança.
No caso do Jenkins, a autenticação integrada é muito frágil: nunca use os mecanismos de autenticação integrados no Jenkins. Melhor optar por um mecanismo de terceiros (SAML, LDAP, Google…), com plugin Role-based Authorization Strategy (“RBAC”). E tenha extremo cuidado com o admin conta.
Cuide de como o trabalho e pipeline arquivos no Jenkins são manipulados. O mesmo com Plug-in de configuração como código e seus arquivos de configuração, que se aplicam à configuração do Jenkins.
Mudando de auto-hospedado CI/CD sistemas para SaaS baseados em nuvem elimina alguns riscos potenciais, permitindo o movimento lateral dentro da rede da organização, mas adiciona outros, como ter que abrir conexões externas entre os sistemas internos existentes e os externalizados CI/CD ferramenta.
As organizações devem exercercise o devido cuidado no endurecimento do CI/CD sistema, começando com as configurações mais restritivas e abrindo gradualmente com as permissões mínimas necessárias para o pipeline passos.
Configurando a segurança em CI/CD ferramentas podem ser uma façanha complexa. Muitas têm plugins ou extensões que têm a maioria das vulnerabilidades e precisam ser atualizadas.
Scanners de configuração incorreta de segurança para ferramentas tão complexas ou benchmarks podem ajudar.
Injetando código em pipeline comandos para diversão e lucro
M3M3N70: Você já usou Untrusted Code Checkouts, ações e scripts vulneráveis à injeção de comando?
Esta seção mostra que pipeline em si pode ter erros de codificação que permitem que atores mal-intencionados injetem execução arbitrária de código no pipeline sem mudar o pipeline fonte em si. Por exemplo, usando um PR
Um primeiro exemplo de infeliz fluxo de trabalho do GitHub:
# INSECURE. Provided as an example only.
on:
pull_request_target #1
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: $ #2
- uses: actions/setup-node@v1
- run: |
npm install #3
npm build
# ... more steps ...
Combinando pull_request_target o gatilho de fluxo de trabalho com uma verificação explícita de um PR não confiável é uma prática perigosa que pode levar ao comprometimento do repositório. No exemplo, a infeliz combinação de:
pull_request_targetevento, que por padrão tem permissão de gravação para o repositório de destino e segredos do repositório de destino, mesmo de bifurcações externas, e é executado no contexto do repositório de destino do PR,- verifique o código PR da fonte, repositório não confiável,
- acionar qualquer script que possa operar em conteúdos controlados por relações públicas, como no caso de
npm installe - não usar uma condição para o acionamento
pull_request_targetevento será executado somente se algum tipo de rótulo 'este PR foi verificado' for atribuído ao PR (usuários externos não podem atribuir rótulos ao PR).
Um segundo exemplo usa uma entrada não confiável (de um problema, comentário ou pull request) como fonte para argumentos passados para um pipeline comando por meio de expressões. Isto é o pipeline versão da vulnerabilidade de injeção de comando do sistema operacional.
- name: Check title
run: |
title="$"
if [[ ! $title =~ ^.*:\ .*$ ]]; then
echo "Bad issue title"
exit 1
fi
A operação run gera um script de shell temporário baseado no modelo, com $ substituído, tornando-o vulnerável à injeção de comando shell. Um invasor com uma conta falsa do GitHub pode criar um problema com um título a"; bad_code_goes_here;#e bum!
Fúria do Pântano: Ah, esses caras estavam abrindo a porta para injeção de comando simplesmente abrindo um problema…
Havia vulnerabilidades de execução de código nas ações do GitHub, como comentário gajira, agora corrigido. Por favor leia “Entrada não confiável em fluxos de trabalho do GitHub” para maiores detalhes.
A moral da história: Nunca verifique e crie PRs de fontes não confiáveis sem primeiro revisar o PR. 'Não confiável' aqui, a menos que esteja sob autenticação draconiana de proveniência, pode significar qualquer conta de desenvolvedor potencialmente sequestrada.
Implantação não intencional de malware aqui!
Implantação contínua é o clímax da automação, mas esse clímax pode ser frustrado pela falta de controles de aprovação apropriados no pipeline fluxo.
Os riscos da implantação totalmente automatizada a partir da origem commit aos sistemas de produção incluem o potencial de implantação de códigos maliciosos em ambientes de produção sem serem detectados, bem como o potencial de erros no processo de implantação causarem interrupções ou interrupções.
Para mitigar esses riscos, muitas vezes é recomendado que as organizações implementem uma “pausa brusca” em seu processo de implantação, o que requer aprovação humana antes que as versões sejam implantadas nos ambientes finais.
Eles estão fechando as portas
Fúria do Pântano:Essas senhas padrão alegres em CI/CD ferramentas estão sendo apagadas. Acessando o
/var/lib/jenkins/secrets/initialAdminPasswordagora é uma pista morta. Muitas ferramentas agora fornecem 2FA, que a Covid tornou popular, e até mesmo o macaco de código mais preguiçoso que existe está usando-o!M3M3N70: Estamos lutando contra o 2FA, mas não é tão fácil. É difícil fazer spear-phishing com esses caras, pois “Scatter Swine” fez com Twilio. Com as chaves WebAuthn é muito mais difícil. Pelo menos, podemos tentar roubar cookies para contornar o MFA, mas precisa entrar na caixa do desenvolvedor.
A autenticação multifator é um bom passo na direção certa para limitar o risco de vazamento de segredos de autenticação. A maioria das ferramentas DevOps modernas oferece suporte a MFA. E chaves de autenticação em WebAuthn/U2F (veja Projeto FIDO2) são talvez a melhor opção para MFA em DevOps, se gerenciados adequadamente.
Fúria do Pântano: O pessoal do DevOps está acordando. Eles têm o maldito “menor privilégio” em seu sangue. E eles não são mais macacos de código. Agora somos pegos em flagrante pelos revisores.
Na verdade, pipelines agora estão um pouco mais robustos do que há alguns anos, com ações e scripts fracos removidos e com etapas adicionais de testes de segurança que até detectaram nossos droppers escondidos em sigilo commitse pacotes que sequestramos.
Pergunta para o leitor: o processo de construção do software a partir das fontes e implantação na produção é um negócio arriscado? Você consegue ver seu DevOps no estágio de bons tempos para os bandidos?
Recomendações finais
Por onde começar CI/CD pipelines?
A primeira recomendação é simples aqui: com cuidado rever pipelines (eles são crítico recursos) para questões de segurança. As revisões são caras, mas necessárias e devem ser feitas de maneira adequada. Os revisores devem estar cientes do que observar. Cada etapa deve ser verificada quanto a falhas.
Talvez uma combinação de revisores especializados armados com scanners automatizados de códigos maliciosos possa ajudar.
A segunda recomendação é treinar desenvolvedores que escrevem pipelinese mantê-los em segurança. Coisas a considerar:
- Como lidar adequadamente com a autenticação com serviços internos e em nuvem, evitando o incômodo de lidar com credenciais de longo prazo.
- Como limitar pipelines para o conjunto exato de recursos aos quais ele precisa acessar. O princípio do menor privilégio brilha novamente.
- Como escrever os passos para fazer pipelineÉ reproduzível, como fixação de versão e evita vulnerabilidades de injeção de comando.
- Como aprovar implantações da perspectiva de segurança (elas são outras!): qual segurança standards devem ser correspondidos e como adicionar verificações/portões correspondentes no pipelines.
Uma terceira recomendação é configurar o CI/CD sistema com o devido cuidado. Autenticação forte, sem senhas padrão ou configurações inseguras, privilégios mínimos… Cuide das vulnerabilidades nos plugins e extensões instaladas. Este pode ser o foco dos próximos posts, fique atento.
A quarta recomendação é aproveitar o CI/CD pipelines para automação de segurança. Análise de código fonte (SAST), análise da composição da fonte (SCA), vazamentos de segredos, ferramentas anti-malware, scanners de segurança de contêineres ou detectores de tempo de execução automatizados (DAST e malware) podem ser executados rotineiramente no pipeline. E sua organização pode impor standards sobre cobertura de varredura de segurança em CI/CD.
Lembre-se de que essas ferramentas ainda não eliminam a avaliação de especialistas da equação; caso contrário, você poderá ter uma falsa sensação de segurança.
Se você é adepto dos dez primeiros do OWASP, um belo projeto recente é o Top 10 OWASP CI/CD Risco de segurança.
Nota de isenção de responsabilidade
(1) Os exemplos neste post estão usando o GitHub como SCM, AWS como provedor de nuvem e GitHub Actions ou Jenkins como CI/CD ferramenta. Elas não são mais fracas/seguras do que suas alternativas. Nenhuma intenção de má imprensa! Essas ferramentas são poderosas e precisam ser usadas apropriadamente.
(2) M3M3N70 e ferrolhos de sobrepor podem ser usados para proteger uma porta de embutir pelo lado de fora. Alguns kits de corrente de segurança também permitem travamento externo com chave ou botão giratório. Fúria do Pântano são personagens fictícios. Qualquer semelhança com pessoas ou grupos, vivos ou mortos, é mera coincidência... ou será?
Para ler mais
- Haymore, A. et al. “10 histórias reais de como fizemos concessões CI/CD pipelines ”. Grupo NCC, janeiro de 2022.
configure-aws-credentialsAção GitHub e ferrolhos de sobrepor podem ser usados para proteger uma porta de embutir pelo lado de fora. Alguns kits de corrente de segurança também permitem travamento externo com chave ou botão giratório. Configurando o OpenID Connect na Amazon Web Services para obter detalhes sobre como executar comandos da AWS para implantação em fluxos de trabalho do GitHub.- Lobacevski J. “Mantendo suas ações e fluxos de trabalho do GitHub seguros Parte 1: Prevenindo solicitações de pwn”. Laboratório de segurança GitLab, dezembro de 2020.
- Lobacevski J. “Mantendo suas ações e fluxos de trabalho do GitHub seguros Parte 2: Entrada não confiável”. Laboratório de segurança GitLab, janeiro de 2021.
- OWASP. “OWASP Top 10 CI/CD Riscos de segurança”. Julho de 2022.
- Saltzer J. e Schroeder M. “A Proteção da Informação em Sistemas Informáticos”. Abril de 1975. Os princípios de segurança evoluíram com a tecnologia, mas 47 anos depois a maioria das ideias de S&S permanecem em vigor.
- NCSC do Reino Unido. “Proteja a construção e a implantação pipeline". Centro Nacional de Cibersegurança do Reino Unido, fevereiro de 2019.
