Em um blog divulgado pela Pen Test Partners, os pesquisadores disseram que a resposta demorou muito para esse tipo de falha. A SonicWall rebateu dizendo que a empresa respondeu prontamente e nenhuma vulnerabilidade foi explorada.
De acordo com o blog, os invasores podem ter aproveitado potencialmente um IDOR para acessar o serviço de nuvem SonicWall. Um IDOR é uma falha em uma API ou aplicativo da web que não verifica a autorização corretamente, permitindo que um invasor acesse dados não autorizados.
“Usando este grau de acesso, um hacker pode modificar regras de firewall e / ou acesso VPN, dando a si mesmo acesso remoto a qualquer organização”, disse Ken Munro, sócio e fundador da Pen Test Partners, à SC Media. “Um hacker pode injetar ransomware ou qualquer outro tipo de ataque. O IDOR permitia que qualquer usuário fosse adicionado a qualquer grupo em qualquer organização. Tudo o que um usuário precisava era sua própria conta e eles poderiam adicioná-la ao grupo de qualquer outra pessoa por meio de um serviço de nuvem pública. ”
Em uma declaração por e-mail para a SC Media, a SonicWall disse que uma vulnerabilidade em seu sistema de registro de produto baseado em nuvem foi rapidamente pesquisada, verificada e prontamente corrigida em 26 de agosto. Cerca de duas semanas antes, a SonicWall disse ter identificado a vulnerabilidade relatada como parte de seu PSIRT programa (a notificação de Pen Test Partners) e rapidamente criou uma correção que passou por testes completos e certificação.
A SonicWall afirma que em nenhum momento detectou ou tomou conhecimento de qualquer tentativa de exploração da vulnerabilidade no sistema de registro de produto baseado em nuvem. A empresa diz que a correção foi aplicada com sucesso ao sistema em nuvem e diz que nenhuma ação é necessária por parte dos usuários finais.
Mas Munro afirmou o contrário, dizendo que depois de vários dias de estímulo, a Pen Test Partners entrou em contato com o CEO da Sonic Wall, Bill Conner, que respondeu duas horas após ser contatado. A correção foi executada apenas dois dias depois – 17 dias após a Pen Test Partners entrar em contato com a empresa.
“Não deveríamos ter procurado o CEO para acelerar esse problema”, disse Munro. “Havia apenas uma parte da API que apresentava a falha. Ele deveria ter sido retirado, mas deixou a base de clientes exposta por pelo menos 14 dias. Este patch deveria ter sido feito muito rapidamente. ”
De acordo com a SonicWall, no momento da descoberta inicial, a empresa revisou os dados de conexão anteriores e determinou que nenhuma conta havia sido explorada e que o risco de exploração era extremamente baixo.
“Um ator de ameaça exigiria informações de conta muito específicas e tempo para tirar vantagem do sistema”, disse o comunicado. “E qualquer tentativa de exploração acionaria um alerta de segurança automatizado para o proprietário legítimo da conta, bem como para a equipe de segurança da SonicWall, devido aos protocolos de segurança em camadas da SonicWall.”
Tarik Saleh, engenheiro de segurança sênior e pesquisador de malware da Domain Tools, disse que esses conflitos entre pesquisadores de segurança e fornecedores sobre tempos de resposta são muito comuns.
“As divulgações do Bug Bounty são um programa realmente benéfico para as empresas que participam delas e para os pesquisadores de segurança de chapéu branco que dedicam seu tempo e energia para ajudar a tornar a Internet um lugar mais seguro”, disse Saleh. “Infelizmente, vimos conflitos entre pesquisadores e empresas, e este é outro exemplo.”
Saleh disse que os pesquisadores nem sempre sabem como as empresas operam com o desenvolvimento de correções de vulnerabilidade, fazendo testes exaustivos nas correções e colocando-as em produção. Embora Saleh tenha dito que a SonicWall poderia ter feito um trabalho melhor para se comunicar com os pesquisadores, é, em última análise, a decisão do fornecedor sobre o quão transparente eles querem ser com seu processo de resposta a incidentes e a divulgação dessas informações para um pesquisador.
“De um modo geral, 17 dias para corrigir esse tipo de vulnerabilidade é muito tempo com o risco que representa para a enorme base de clientes”, disse Saleh. “Parece que há um grande espaço para melhorias em como o PSIRT da SonicWall faz a triagem de vulnerabilidades informadas a eles, como eles se comunicam e coordenam quais correções precisam acontecer com as equipes apropriadas e como envolver os pesquisadores com mais informações para não deixá-los pendurados.”
Rick Moy, vice-presidente de marketing da Tempered Networks, acrescentou que o CEO da SonicWall, Conner, fez um bom trabalho ao compreender a importância do problema e agiu rapidamente assim que a informação foi apresentada a ele.
“Isso espalha o senso de urgência por toda a organização”, disse Moy. “No entanto, em 2020, uma vulnerabilidade indireta de referência de objeto seguro em um serviço de segurança em nuvem é difícil de desculpar, já que está no OWASP Top 10 desde 2007. Como fornecedores de segurança, precisamos nos manter em um padrão mais alto.”
Uma cidade na Carolina do Norte e um escritório de advogados distritais cobrindo quatro condados…
O surgimento da Nytheon AI marca uma escalada significativa no cenário das plataformas (LLM) de…
Um pesquisador de segurança revelou uma vulnerabilidade crítica de injeção de SOQL no controlador interno…
Falha permite que invasores manipulem o agente de um usuário por meio de um problema…
Um exploit de dia zero, dirigido aos firewalls FortiGate da Fortinet, foi descoberto à venda…
A família SHELBY mostra um exemplo preocupante de malware moderno com design modular, sofisticado e…