0 
0 Os pesquisadores de segurança da Oxeye descobriram várias novas variantes de alta gravidade das vulnerabilidades IDOR (Insecure Director Object Reference) (CVE-2022-31671, CVE-2022-31666, CVE-2022-31670, CVE-2022-31669, CVE-2022-31667 ) no projeto Harbour, formado pela CNCF, o popular registro de artefatos de código aberto da VMware.
Harbour é um projeto de registro nativo de nuvem de código aberto que armazena, assina e verifica conteúdo. Ele pode ser integrado a vários registros do Docker para fornecer recursos de segurança, como gerenciamento de usuários, controle de acesso e auditoria de atividades.
Classificado como uma vulnerabilidade de controle de acesso, o IDOR ocorre quando um aplicativo usa a entrada fornecida pelo usuário para acessar objetos diretamente. O IDOR é uma ameaça de alta gravidade e é considerado o risco de segurança de aplicativo da Web mais sério na lista dos 10 principais da OWASP mais atual .
Os sistemas de controle de acesso são projetados para impor políticas que impeçam os usuários de agir fora das permissões pretendidas. As falhas de controle de acesso geralmente levam à divulgação não autorizada de informações, modificação, exclusão de dados ou ao desempenho de funções de negócios fora dos limites de um usuário. Nesta pesquisa, o IDOR foi descoberto no VMware’s Harbor, que permite aos usuários gerenciar melhor seus artefatos de aplicativos. O controle de acesso baseado em função (RBAC) em vigor geralmente é uma prática recomendada contra vulnerabilidades do IDOR, mas esta pesquisa testou essa teoria com resultados surpreendentes.
A vulnerabilidade IDOR no Harbor leva à divulgação de políticas de webhook sem autorização. O Harbour permite que os usuários configurem políticas de webhook para receber notificações sobre determinados eventos no repositório, por exemplo, quando um novo artefato é enviado ou quando um existente é excluído. Depois que uma política de webhook é adicionada, um usuário do Harbor pode visualizar detalhes das políticas de webhook criadas. Neste exemplo, a vulnerabilidade ocorreu porque o Harbor apenas tentou validar se o usuário solicitante tinha acesso à ID do projeto especificada na solicitação. Mas não conseguiu validar que o ID do webhook solicitado pertencia ao ID do projeto especificado.
Outra variante do IDOR leva à divulgação dos logs de execução do trabalho. O pré-aquecimento P2P (peer-to-peer) permite que os usuários do Harbour se integrem a mecanismos P2P, como Dragonfly ou Kraken, para distribuir imagens do Docker em escala. Ao combinar essa vulnerabilidade IDOR com a vulnerabilidade “ ParseThru ”, um invasor pode ter a capacidade de ler camadas de imagem do Docker para as quais não possuem credenciais de acesso.
“Embora o controle de acesso baseado em função (RBAC) seja importante para manter uma posição de segurança forte, não é o objetivo final da defesa absoluta do sistema contra vulnerabilidades do IDOR”, disse Ron Vider , CTO da Oxeye. “Conforme revelado pelos pesquisadores de segurança da Oxeye, Gal Goldshtein e Daniel Abeles, implementar práticas mais robustas que incluem definir funções estritas para terminais de API, simular agentes de ameaças para testar essas funções na tentativa de quebrar modelos de permissão e evitar duplicação de propriedades para manter uma única fonte. da verdade pode garantir a resiliência.”
Todas as variantes do IDOR mencionadas neste anúncio foram comunicadas às equipes de VMware Security Response e Harbour Engineering, que colaboraram prontamente para uma resolução rápida e eficaz. Todos foram abordados (corrigidos) na versão mais recente do Harbor.
FONTE: HELPNET SECURITY