CVE-2021-34371

O Neo4j com o shell server habilitado expõe um serviço RMI que desserializa quaisquer objetos Java arbitrários que lhe sejam entregues, por exemplo por meio de setSessionVariable. Essa é a clássica armadilha de desserialização insegura: como existem gadget chains exploráveis nas dependências, um atacante que consiga alcançar a porta RMI envia um payload serializado malicioso e obtém execução remota de código no host do banco de dados. Não autenticado, remoto, sem interação — a desserialização é o exploit por inteiro.

Bugs de desserialização Java são uma classe de ataque madura e bem instrumentada; payloads de gadget chain prontos existem e são reutilizados, de modo que a transformação em arma é rápida assim que um listener alcançável é encontrado. A pré-condição crítica, e é uma pré-condição real, é que o shell server precisa estar habilitado e sua porta RMI acessível. Isso reduz consideravelmente a exposição — muitas implantações não o executam —, mas qualquer instância que o faça, com a porta em uma rede acessível, é um alvo direto de RCE para qualquer um que esteja varrendo em busca de serviços RMI expostos.

Para nós, isto é mais uma caça por alcançabilidade e configuração do que uma varredura de versão. Identificaríamos instâncias do Neo4j na 3.4.18 ou anteriores e, então, verificaríamos as duas coisas que de fato a condicionam: o shell server está habilitado e essa porta RMI está exposta além do localhost ou de um segmento confiável? Um listener exposto é uma emergência; um shell server desabilitado ou uma porta atrás de firewall derrubam a mesma versão para bem longe no topo da lista. Bloquear a porta RMI é um patch virtual imediato onde a atualização está atrasada.