Como sobreviver a um RCE · Silva97

Alguém com dinheiro suficiente pega sua IA favorita, escolhe um alvo e diz para ela: "ache um RCE e escreva um exploit estável". Algumas horas depois, pimba: 0-day encontrado, exploit pronto, milhões de máquinas vulneráveis no mundo. Não é tão simples assim, mas vamos fingir que é para preservar a concisão do texto.

Neste artigo eu vou falar um pouco sobre o problema da moda de IAs achando vulnerabilidades em tudo, sobre porque isso é mais pânico generalizado do que um problema realmente grave e como resolver esse problema no seu sistema (sim, tem solução).

Vou te responder a pergunta: Por que empresas como Google, Facebook, Microsoft e por que exércitos e governos do USA, Rússia, China etc. não ficam desesperados quando um serviço que eles usam nos seus sistemas tem uma falha de segurança grave? Por que, para eles, isso não é aterrador como é para nós, meros mortais?

Eu vou te ensinar a ter paz de espírito igual a eles... Mas por enquanto você ainda deve entrar em desespero e atualizar seu PHP. Já fez isso? Faz agora! Atualizou? Pronto, pode ficar calmo de novo... Pode voltar a fingir que seu sistema não tem falhas de segurança.

Para os que não sabem o que é RCE, exploit ou 0-day: continue não sabendo. O que os olhos não veem o coração não sente. Melhor ainda: pare de usar computadores e vá morar na floresta coletando e caçando sua própria comida. Para quê se estressar?

Para os que ainda pretendem continuar vivendo em sociedade (péssima ideia), um rápido glossário de termos que provavelmente você vai continuar ouvindo falar por um bom tempo:

RCE (Remote Code Execution) é um tipo de vulnerabilidade onde um atacante consegue, de alguma forma, executar código arbitrário em um computador remoto.
Exploit é um código que automatiza a exploração de uma ou mais de uma vulnerabilidade, afim de causar algum impacto de segurança à um sistema.
0-day é uma vulnerabilidade de segurança que ainda não é conhecida pelos responsáveis por manter o sistema e/ou a vulnerabilidade ainda não tem patch de correção.
1-day é uma vulnerabilidade que já tem patch de correção, mas a correção foi lançada recentemente.
n-day é uma vulnerabilidade que já foi corrigida há um tempo, mas ainda é explorada em sistemas desatualizados.
ITW (In The Wild) é uma vulnerabilidade que está sendo explorada ativamente em ambientes reais por cibercriminosos.
APT (Advanced Persistent Threat) é uma ameaça (indivíduo ou grupo) que executa ataques sofisticados contra sistemas. Muitas vezes explorando 0-days e instalando malwares (como rootkits) para manter o acesso persistente ao sistema explorado. Em termos simples: são caras bons no que fazem e que estão no nível de serem ameaças para big techs e governos.

Pronto, da próxima vez que você ver um pesquisador de segurança falando uma coisa esquisita como "exploit RCE 0-day usado ITW por um APT" você vai entender do que se trata e não vai parecer só buzzword dropping.

O problema

Antes: encontrar um 0-day em um software amplamente utilizado por empresas (como o runtime do PHP) poderia demorar meses de pesquisa feita por uma pessoa bastante capacitada tecnicamente.

Agora: alguém pode pagar plano premium de um modelo de IA, escrever um prompt pequeno e deixar os agentes trabalharem de forma autônoma. Algum tempo depois, por um custo relativamente baixo, o agente escreve um exploit funcional para você.

Olhando de forma superficial, parece que "qualquer pessoa" com acesso a um modelo decente de IA consegue encontrar 0-days. Ou, no mínimo, mesmo que não seja "qualquer pessoa", mesmo que exija alguma competência em pesquisa de segurança para saber usar a IA corretamente, ainda sim a produtividade aumentou muito.

Então, se antes um APT conseguia um 0-day em 6 meses de pesquisa, agora ele consegue em alguns dias.

Mas segurança da informação sempre foi baseada em defesa e ataque: segurança defensiva e segurança ofensiva. Então, pesquisadores de segurança encontrando e reportando vulnerabilidades não é novidade, existe desde o século passado.

Em tese, isso só significa que todo mundo ficou mais produtivo: cibercriminosos ficaram mais rápidos em acharem 0-day, mas pesquisadores de segurança também. Isso não mudou o cenário de segurança ofensiva, só acelerou as coisas. O "equilíbrio de poder" ainda é o mesmo se os dois lados foram acelerados de forma equivalente.

Achar 0-day rápido não é um problema de verdade. Tá mais para solução do que problema: quanto mais rápido pesquisadores de segurança encontrarem 0-days, melhor para o software em questão.

O problema verdadeiro é que a segurança defensiva não acelerou junto com a ofensiva. Estamos muito mais rápidos em encontrar 0-days, mas estamos na mesma velocidade em termos de proteger os sistemas.

Cadê o uso de IA em segurança defensiva? Se tem agente atacando, cadê os agentes defendendo?

O problema é que segurança ofensiva é pontual: você escolhe um alvo, faz pesquisa, acha a vulnerabilidade e ataca.

Segurança defensiva é contínua: tem que ser feita todo dia, 24/7, sem folga.

Em outras palavras: para você ter um nível de defesa usando IA tão autônomo e competente quanto o ataque, você teria que arcar com um custo mensal que levaria sua empresa à falência.

Segurança defensiva não pode ser acelerada tanto quanto a ofensiva. É financeiramente impraticável.

O pânico generalizado

No dia 21 de outubro, horas antes do patch de correção do PHP ser lançado, o pesquisador de segurança @J4ck3LSyN no Twitter fez uma publicação compartilhando sua pesquisa, onde ele havia conseguido fazer um exploit estável para explorar as vulnerabilidades que ficaram conhecidas como PHP2Shell: CVE-2026-109618 e CVE-2026-109619.

Sem querer o tweet dele foi parar no main stream e não deu outra: ele foi atacado... e muito. Ele recebeu bastante ódio, ameaças de morte e gente jurando de pé junto que isso vai prejudicar a carreira dele na área de cybersec (risos)...

Sim, na área de cybersec. Aquela área lá que começou contratando criminosos condenados porque eles eram os mais capacitados para proteger os sistemas das empresas e os únicos que tinham experiência com isso (risos). Aquela área que as pessoas de fora juram que é consistida por anjos abençoados por Deus que nunca fazem nada de errado (risos)(risos). Os tal dos hackers "ÉtIcOs" que adoram um leak do banheiro, tretam entre si 2 vezes por semana e se você vacilar com teu celular em um evento da área até tua mãe é hackeada (risos)(risos)(risos). Sim, aquela área.

(mas vocês adoram se iludir, né?)

Dá para ver um pouco das críticas que ele recebeu aqui:

Se você acha que ele fez alguma coisa de errado ou acha que isso vai prejudicar a carreira dele, deixa eu quebrar suas ilusões: isso sempre aconteceu e sempre vai acontecer.

Sempre que anunciam uma vulnerabilidade nova, sempre ocorre uma "corrida" para ver quem escreve um exploit primeiro (por motivos de ego). E deixa eu te contar o babado: essa galera que participa da "corrida" não assinou contrato nenhum, eles não estão infringindo nada nem cometendo nenhum crime, nem sequer estão infringindo código de ética (isso é para quem reportou a vulnerabilidade).

Acontece que isso, normalmente, não vai parar no main stream e só o pessoal interessado em pesquisa de segurança (todos os 5) ficam sabendo. Por azar do coleguinha, dessa vez foi pro main stream. O algoritmo do Twitter sacaneou o cara ou alguém com muitos seguidores não usou o cérebro antes de reclamar publicamente sobre o tweet dele -- não sei bem como ocorreu.

Mas a revolta que caiu sobre o @J4ck3LSyN serviu para evidenciar que as pessoas estão em pânico ou, no mínimo, muito estressadas por causa da IA.

Deixa eu te contar: o pânico não é justificável. O teu sistema já estava vulnerável ANOS antes do @J4ck3LSyN sequer sonhar em fazer aquele tweet. Você acha que o risco foi criado por ele ou no dia 21? Não foi, amiguinho.

O que os olhos não veem o coração não sente, né? As pessoas só se preocupam com segurança quando uma vulnerabilidade é divulgada, sem se tocarem que a vulnerabilidade já existia meses ou até mesmo anos antes dela ser divulgada.

As vulnerabilidades do PHP2Shell existiam desde 2012, são 14 anos de existência antes de você atualizar teu PHP às pressas. Você pode até se iludir achando que ninguém conhecia a vulnerabilidade antes disso, mas quem te garante isso? Vulnerabilidade não divulgada não é o mesmo que não conhecida. Várias pessoas podem ter descoberto essa vulnerabilidade em 2012 e explorado ela desde então. Vai saber?

Mesmo que não tenham descoberto tão cedo, ainda sim alguém pode ter usado IA para achar essas vulnerabilidades ano passado e ter explorado elas desde então.

Você não deveria ter medo de vulnerabilidades conhecidas, essas já estão resolvidas ou perto de serem resolvidas. Seu medo deveria estar nas vulnerabilidades sobre as quais ninguém faz tweet ou lança patch...

Não é uma coisa ruim que as pessoas descubram e divulguem vulnerabilidades. O que é ruim é que elas descubram e guardem a informação para si ou vendam para clientes específicos.

Estão reportando muitas vulnerabilidades achadas por IA? Tão fazendo muito barulho nas redes sociais sobre isso? Ótimo, fique aliviado. Fique em pânico é com o silêncio, ele que deveria te assustar.

Muito desse pânico generalizado ocorreu porque IA trouxe o tema "exploração de vulnerabilidades" para o main stream. Dizem que 0-day é o assunto do momento entre as Kardashians. Fiquei sabendo que o Brad Pitt postou um exploit no Instagram dele. Dizem que o Keanu Reeves ajudou a escrever.

O assunto ficou popular. E já vimos algo parecido acontecer antes: Rust tornou o assunto "memory safety" em um assunto popular. Antes de Rust, PhDs viciados em type theory, Haskell e lambda calculus falavam de memory safety. Eles sabiam do que estavam falando, então tudo certo.

Mas aí veio Rust e tornou o assunto popular, daí o "povão" começou a falar de memory safety. O problema é que 99% das pessoas que falavam sobre memory safety nem sequer entendiam o que era memory safety e, por consequência, falavam bobagens.

A história está se repetindo: IA trouxe "exploit" e "exploração de vulnerabilidades" para a boca do "povão". 99% da galera falando sobre o assunto não entende de segurança. O resultado não poderia ser outro: estão falando bobagens.

A solução

Uma coisa que profissionais de segurança já entendem, mas os desenvolvedores custam entender: O seu sistema É vulnerável! Não é que ele "pode" ser vulnerável, ele é. Não é que "pode" ter uma vulnerabilidade, ele tem. Não é que "talvez" alguém ache uma vulnerabilidade, vão achar.

É mais provável que a terra seja uma pirâmide oca cor-de-rosa do que seu sistema esteja "seguro" só porque ele está totalmente atualizado com os últimos patches de segurança. Atualização não é proteção.

Não adianta você entrar em pânico por causa do runtime do PHP, atualizar tudo correndo, mas enquanto isso teu próprio código está cheio de falhas de segurança (não é que "talvez" esteja, ele está). Ataques na vida real ocorrem com muito mais frequência explorando vulnerabilidades no próprio código da aplicação do que no runtime utilizado por ela. Pelo simples fato de que é tecnicamente mais fácil achar e explorar vulnerabilidades no código de uma aplicação web do que em um sistema como PHP, nginx ou o kernel do teu SO.

Por isso não adianta você achar que "agora" teu sistema tá seguro porque você atualizou teu PHP. Não está, nunca esteve. Não é que "talvez" não esteja, não está.

Mas calma, não precisa fugir para a floresta. Os militares já tiveram essa epifania de que todo sistema é vulnerável e já elaboraram uma solução para esse problema, mesmo antes dos computadores existirem.

"Segurança" e "defesa" parece estar atrelado à computadores porque, bem, a gente trabalha com eles. Mas segurança já existia muito antes do Alan Turing formular a Máquina de Turing.

Defesa em profundidade, basicamente esta é a solução e o termo que você vai querer pedir para sua IA favorita te explicar. Quando militares querem defender uma base ou posição, eles não fazem isso assumindo que sua linha de defesa não será penetrada. Eles fazem o contrário: eles assumem que ela será destruída e formulam sua estratégia de defesa a partir desta premissa.

Assim como muitos termos da segurança da informação, defesa em profundidade também tem origem militar. Quando queremos defender um sistema, é importante compreender que ele tem uma superfície de ataque (attack surface): que são as partes do sistema que estão expostas à atacantes e terão vulnerabilidades que podem ser exploradas pelos mesmos. É a "casca" do teu sistema, a primeira parte que será atacada antes de mais nada.

Um erro comum e que deve ser evitado a todo custo é tentar proteger um sistema simplesmente tentando proteger sua superfície de ataque. O PHP é um exemplo de superfície de ataque e o RCE nele é uma vulnerabilidade em uma das superfícies de ataque do teu sistema.

O jeito "certo" de defender um sistema é assumir que a superfície de ataque tem vulnerabilidades (não é que "pode ter", tem) e que elas serão exploradas. Uma vez que você tem isso como premissa, como você protege seu sistema? É aqui que seu medo deveria estar sendo utilizado.

Eu não vou ensinar "como fazer defesa em profundidade" como se houvesse um passo a passo para isso. É complexo e não vou fingir que não é. Cada caso é um caso, vai depender da realidade do teu sistema e do teu orçamento. Mas já falei um pouco sobre o tema aqui: https://www.tabnews.com.br/Silva97/dividir-para-proteger.

Mas, uma vez que você conhece e entende o que é defesa em profundidade, assim você entende que ter um RCE no teu sistema não é motivo para pânico, não é o fim do mundo. Vamos pegar esse exemplo do PHP: imagina que alguém tenha um exploit estável para o RCE e usa ele no teu sistema e consegue uma shell com sucesso.

Se o teu serviço de PHP estiver isolado do resto do sistema usando soluções de sandboxing, containerização ou virtualização, obter uma shell não é o fim do mundo: o atacante está isolado e não tem muito o que possa fazer.

Antes disso, se você hardenizou o serviço do PHP e configurou coisas como AppArmor/SELinux e o seccomp, é capaz do exploit nem funcionar pelo processo não poder executar as syscalls necessárias.

Mas digamos que você fez as duas coisas: Processo do PHP hardenizado e isolado em um container. O atacante explora o RCE, depois explora uma vulnerabilidade no kernel Linux para fazer um container escape.

Digamos que mesmo com o seccomp configurado, o exploit de container escape dele consiga rodar. Acabou? É fim de jogo? Não, porque você também pode hardenizar o próprio kernel usando LKRG, por exemplo, entre outras formas de fazer isso.

Digamos que você fez as 3 coisas, mesmo assim o atacante conseguiu o container escape: agora ele tem acesso root ao sistema host. Acabou? Ainda não, porque você ainda pode fazer controles de acesso e isolamento de rede na sua rede interna. Só porque ele obteve acesso a um sistema não quer dizer que precise obter acesso aos outros de brinde.

Mas veja que o atacante tem que passar pela superfície de ataque, pelo isolamento do processo usando container, teve que dar bypass em soluções de segurança do kernel, teve que dar bypass no hardening do kernel para só então conseguir acesso parcial ao sistema. Isso é muito mais complicado do que só rodar um exploit para um RCE do PHP.

Mediante tudo isso, defesa em profundidade não é apenas dificultar o ataque (como exemplificado acima), mas também detectar ele: enquanto o atacante está ocupado tentando explorar várias camadas de defesa, ele pode ser detectado por soluções como um EDR e reportado para um analista de SOC verificar a situação.

Se você tem as duas coisas: tanto meios de dificultar o ataque quanto meios de detectá-lo, você pode ficar em paz na próxima vez que o PHP tiver um RCE. Porque você sabe que não é tão fácil explorar teu sistema e, mais difícil ainda, é fazer isso sem ser detectado e barrado antes de ter sucesso.

Isso é defesa em profundidade. É por causa dela que a Google ou o exército do USA não entra em desespero por causa de tweets ou CVEs. Estude e aprenda a fazer defesa em profundidade no teu sistema se quiser levar segurança à sério.