Vulnerabilidade do N-central expõe riscos para provedores de serviços gerenciados: o que o incidente da N-able representam para a segurança do seu RMM?

Seu RMM tem acesso administrativo a cada dispositivo que você gerencia — sem supervisão, a qualquer hora, em todos os ambientes de clientes que você administra. Esse acesso não é um recurso. É o produto. E isso faz do seu provedor de RMM uma das escolhas mais importantes da sua estrutura, não pelo que ele faz quando tudo está dando certo, mas pelo que acontece quando algo dá errado.

Em 1º de agosto, a N-able divulgou o CVE-2026-18577, uma vulnerabilidade crítica no N-central — a plataforma de RMM usada por milhares de MSPs para aplicar patches e acessar remotamente cada dispositivo em todos os clientes que administram — que permitia que invasores tomassem o controle administrativo do console sem ter credenciais válidas. Depois de conseguir acesso, os invasores usaram o próprio recurso de controle remoto do N-central para avançar até os endpoints gerenciados, incluindo controladores de domínio, em diversas organizações, até que a N-able lançou uma correção emergencial em 2 de agosto (a publicação da Huntress traz o cronograma completo do incidente). A CISA adicionou a vulnerabilidade ao catálogo de Vulnerabilidades Exploradas Conhecidas na mesma semana e ordenou que órgãos federais dos EUA aplicassem patch em poucos dias.

Quando fiquei sabendo dessa vulnerabilidade, lembrei das discussões que tivemos durante o desenvolvimento do LogMeIn Resolve em 2021, logo após um grande ataque à cadeia de suprimentos divulgado. Um dos nossos leads de engenharia afirmou com coragem que esses ataques continuariam crescendo e que precisávamos fazer algo diferente para proteger nossos clientes. E foi exatamente o que fizemos, com a arquitetura Zero Trust do Resolve, incluindo controles projetados para evitar que uma única invasão da camada de gerenciamento impactasse tudo o que está abaixo dela, ou seja, cada ambiente gerenciado pelo MSP.

A arquitetura do Resolve foi criada partindo do princípio de que o servidor vai ser invadido em algum momento. A mesma pergunta que fizemos a nós mesmos é a que eu faria hoje a qualquer provedor de RMM: Se sua infraestrutura for comprometida, o que um invasor realmente pode fazer? No caso do LogMeIn Resolve, o invasor não teria acesso aos seus endpoints. A chave de assinatura Zero Trust pode impedir que invasores executem ações privilegiadas nos terminais gerenciados — porque ninguém, nem mesmo o provedor, possui essa chave.

A arquitetura é um dos fatores mais importantes, mas não é o único. Há outros aspectos a considerar, então, antes da próxima conversa de renovação ou de avaliar uma nova plataforma, veja aqui seis perguntas que você deve fazer ao seu provedor de RMM.

A maioria dos provedores de serviços gerenciados (MSPs) com quem converso vê o modelo de implantação de RMM como uma preferência da TI, mas, na verdade, essa é uma decisão de segurança que muitas vezes não recebe a devida atenção.

O appliance local tem um problema que costuma passar despercebido. É um servidor que precisa receber patch, ser reforçado e ter proteção de terminais — mas, na prática, isso raramente acontece. Como não é uma estação de trabalho, muitas vezes ele fica de fora do monitoramento por EDR. Não é um serviço em nuvem, então ninguém monitora seu nível de segurança além de você. E ele fica na sua rede com acesso elevado a cada um dos dispositivos que você gerencia.

O incidente da N-able confirmou quase exatamente esse padrão: o appliance do N-central roda em uma versão do Linux protegida e restrita que, segundo os especialistas externos de resposta a incidentes, normalmente não conta com EDR porque é gerenciado como um appliance, não como um servidor.

A implementação nativa em nuvem transfere essa responsabilidade para o provedor. A diferença que isso faz depende totalmente de como o provedor protegeu e auditou essa infraestrutura — é exatamente para isso que servem as perguntas 3 e 6.

Pergunte ao seu provedor: “Se estou usando a versão local do seu produto, qual é minha responsabilidade de proteger esse servidor? Um EDR é compatível e recomendado nesse caso?”

Esta é, sem dúvida, a pergunta estrutural mais importante da lista e deve ser uma das prioridades da conversa com um provedor. A resposta revela praticamente tudo o que você precisa saber sobre a arquitetura de um provedor.

Em uma arquitetura convencional baseada na confiança, o servidor é considerado um nó confiável. Um invasor que consegue acesso administrativo ao servidor herda essa confiança — e passa a poder enviar comandos, scripts e sessões remotas para todos os aparelhos gerenciados conectados a ele. O backend é a porta de entrada para todo o ambiente — e foi exatamente isso que aconteceu no incidente da N-able: depois de invadirem o console, os invasores usaram o recurso integrado de controle remoto para acessar endpoints gerenciados, incluindo controladores de domínio, em várias organizações. Essa é a arquitetura que a abordagem Zero Trust do LogMeIn Resolve foi criada para superar.

Uma arquitetura Zero Trust funciona de maneira diferente. Cada comando enviado para um terminal gerenciado é assinado pela chave privada do técnico — uma chave que nunca sai do computador do técnico. O endpoint verifica a assinatura antes de executar qualquer coisa. Um servidor de backend violado não consegue enviar comandos maliciosos porque nunca teve a chave privada — o backend só possui a chave pública, e a chave privada não pode ser extraída dele. Qualquer comando que falhar nesse teste de assinatura é descartado no dispositivo, em vez de ser executado.

David Bisztrai, VP de engenharia da GoTo da linha de produtos LogMeIn, traz um bom exemplo: "Imagine um cofre grande de um banco. Em um sistema tradicional, invasores cavariam um túnel para entrar, e quando estivessem dentro, encontrariam o verdadeiro tesouro: no nosso caso, os endpoints. O backend se comunica com o dispositivo, o dispositivo confia nele e executa qualquer comando que recebe. Nossa arquitetura Zero Trust parte do mesmo princípio — alguém eventualmente vai encontrar um túnel para nosso cofre. Mas quando chegarem lá, não vão encontrar o tesouro. Eles vão encontrar milhares de pequenos armários, e cada um só pode ser aberto com uma chave de assinatura que está nas mãos do cliente, não nas nossas. Mesmo que você chegue ao cofre, não consegue abrir nada."

Esta é uma questão conceitual, não de patch. Nenhuma hotfix altera o modelo de funcionamento do produto do seu provedor.

Pergunte ao seu provedor: “Se sua infraestrutura fosse totalmente comprometida, o que impediria um invasor de usar sua plataforma para acessar meus endpoints gerenciados?”

Agilidade faz muita diferença. Mas a amplitude da correção faz ainda mais. Esses dois aspectos são distintos, e é justamente na diferença entre eles que está o verdadeiro risco.

Um patch que fecha o vetor de ataque relatado, mas deixa outro próximo aberto, pode gerar uma falsa sensação de que o problema foi resolvido. Patches complementares para vulnerabilidades em RMM são usados de forma generalizada no setor, e o incidente da N-able é apenas um exemplo disso. Invasores exploraram um novo vetor relacionado à correção anterior.

Nem sempre é preciso encontrar uma nova vulnerabilidade. Basta o patch do provedor estar incompleto.

A questão não é só a rapidez para aplicar o patch, mas a forma de garantir que a correção está realmente completa.

Pergunte ao seu provedor: "Quando foi a última vez que você lançou um patch complementar para uma vulnerabilidade que pensava já estar resolvida — e o que seu processo de testes deixou passar na primeira vez?"

Essa é uma questão tanto de logística quanto de segurança. É a pergunta que a maioria dos MSPs só faz depois que um patch já foi lançado há uma semana e metade dos seus servidores auto-hospedados continuam vulneráveis.

Para estruturas hospedadas na nuvem, os provedores distribuem as correções de segurança de forma centralizada — muitos clientes nem percebem que um patch foi aplicado. No caso de implementações locais, essa tarefa fica com você.

O incidente com a N-able trouxe números concretos sobre esse problema. Segundo a telemetria da Huntress em sua própria base de parceiros e clientes, mais da metade dos servidores acessíveis hospedados em nuvem do N-central ainda estavam sem patch no primeiro dia depois do lançamento da hotfix da N-able. Na atualização seguinte, a aplicação de patch na nuvem já tinha cumprido o objetivo, mas quase três em cada dez servidores acessíveis auto-hospedados ainda estavam sem o patch.

“Não dá para entender o atraso na aplicação de patches do setor como algo 'na margem de erro' — são os 10% ou 20% dispositivos mais lentos nesse processo que nunca conseguem acompanhar o ritmo totalmente, e é justamente esse grupo que os invasores estão explorando”, disse Steve Shattuck, Vice-presidente de ecossistemas globais de parceiros da GoTo.

Pergunte ao seu provedor: "Depois de lançada uma atualização crítica de segurança, quantos dos seus clientes normalmente continuam usando uma versão vulnerável 48 horas após o lançamento? Como você tem certeza?"

Criptografia já é o básico. O que realmente importa é se a plataforma aplica controles de permissão, constrói uma trilha de auditoria e oferece ao usuário controle real sobre seu próprio dispositivo. O que de fato diferencia os provedores é o que acontece acima da simples criptografia de sessões.

O acesso não supervisionado merece uma atenção especial aqui. Como ele é configurado? Quem aprova esse acesso? Quem pode revogar? Essas perguntas definem sua exposição — e sua capacidade de olhar um cliente nos olhos e explicar como os sistemas dele estão sendo acessados de fato.

Pergunte ao seu provedor: “Um usuário final pode revogar o acesso remoto não supervisionado por conta própria, sem passar pelo MSP? Onde isso está documentado e como é apresentado ao usuário?”

Existe uma distinção entre um provedor que diz "levamos a segurança a sério" e outro que possui certificações de uma auditoria independente para comprovar sua confiabilidade. O primeiro é uma afirmação. O segundo é uma evidência.

Certificações importantes para perguntar ao provedor: ISO/IEC 27001:2022, SOC 2 Type II, BSI C5. Cada uma representa uma validação externa, auditada, dos controles de segurança — não uma avaliação interna feita pelo próprio provedor. Testes de penetração externos realizados por empresas terceirizadas são mais uma camada importante de consistência, e muitos provedores deixam de fazê-los.

Pergunte ao seu provedor: "Quais certificações vocês possuem e quando foi a última auditoria?" Vocês fazem testes de penetração externos? Podem mostrar o escopo deles?

Nenhum provedor pode prometer nunca sofrer um incidente. E isso também vale para nós. A pergunta honesta nunca foi "esse provedor já teve algum problema?", mas sim "o que a arquitetura deles faz para limitar o impacto quando algo dá errado?"

Um modelo Zero Trust, que isola criptograficamente o acesso ao endpoint de uma possível violação no backend, é estruturalmente mais resiliente — não porque impede todos os ataques, mas porque evita que um tipo de ataque se transforme em uma catástrofe. Essa é uma característica conceitual, de projeto. Ou existe ou não existe.

O LogMeIn Resolve foi desenvolvido com esse modelo, justamente porque nossa equipe de engenharia antecipou que as plataformas de RMM se tornariam alvos valiosos na cadeia de suprimentos. O incidente recente com o N-central reforça por que essa abordagem arquitetural é importante.

Se você usa um RMM do modelo convencional de confiança em servidores, vale a pena fazer estas seis perguntas esta semana, não só no próximo ciclo de renovação.