Antes de ser corrigido, o AttachMe poderia permitir que invasores acessassem e modificassem os volumes de armazenamento OCI de qualquer outro usuário sem autorização, violando assim o isolamento da nuvem. Após a divulgação, a vulnerabilidade foi corrigida em poucas horas pela Oracle. Nenhuma ação do cliente foi necessária.
Potencial Impacto
Antes de ser corrigido, todos os clientes da OCI poderiam ter sido alvo de um invasor com conhecimento de #AttachMe . Qualquer volume de armazenamento não anexado, ou volumes de armazenamento anexados que permitam multi-anexação, podem ter sido lidos ou gravados desde que um invasor tenha seu Oracle Cloud Identifier (OCID), permitindo que dados confidenciais sejam exfiltrados ou ataques mais destrutivos sejam iniciados por manipulação de arquivos executáveis.
Remediação
Dentro de 24 horas após ser informado pela Wiz, a Oracle corrigiu o #AttachMe para todos os clientes da OCI. Nenhuma ação do cliente foi necessária.
Principais conclusões
O isolamento do locatário de nuvem é um elemento-chave na nuvem. Os clientes esperam que seus dados não sejam acessíveis por outros clientes. No entanto, as vulnerabilidades de isolamento da nuvem quebram as barreiras entre os locatários. Isso destaca a importância crucial da pesquisa proativa de vulnerabilidades na nuvem, divulgação responsável e rastreamento público de vulnerabilidades na nuvem para a segurança da nuvem.
O que é AttachMe?
AttachMe é uma das vulnerabilidades de nuvem mais graves relatadas, pois pode ter afetado todos os clientes da OCI. As vulnerabilidades de isolamento de nuvem geralmente afetam um serviço de nuvem específico. No entanto, neste caso, o impacto está relacionado a um serviço de nuvem principal.
Os engenheiros da Wiz descobriram que anexar um disco a uma VM em outra conta não exigia permissões. Isso significa que um invasor em potencial pode ter acessado e modificado dados de qualquer cliente da OCI e, em alguns casos, pode até ter assumido o controle do ambiente.
O fluxo de ataque potencial era simples:
- Descubra o ID (OCID) do volume de uma vítima alvo pesquisando na web ou usando uma permissão de usuário com poucos privilégios para ler o OCID do volume do ambiente da vítima.
- Inicie uma instância de computação em um locatário controlado pelo invasor localizado no mesmo Domínio de Disponibilidade (AD) que o volume de destino.
- Anexe o volume da vítima à instância de computação do invasor, obtendo assim privilégios de leitura/gravação sobre o volume.
A partir daí, um invasor em potencial poderia ter realizado várias ações sérias:
• Exfiltrar dados confidenciais armazenados no volume.
• Pesquise no volume por segredos de texto simples para mover-se lateralmente pelo ambiente da vítima e/ou escalar privilégios.
• Altere os volumes de blocos e os volumes de inicialização existentes, por exemplo. manipulando binários — para obter execução de código quando os volumes foram montados em instâncias de computação.
A Oracle respondeu de forma extraordinariamente rápida quando a Wiz divulgou com responsabilidade sua descoberta do #AttachMe. Como parceiro e cliente da Oracle, Wiz aprecia a colaboração da Oracle e a rápida atenção a esse problema. A Oracle agradeceu à Wiz por descobrir essa vulnerabilidade como parte de seu Critical Patch Update Advisory de julho de 2022.
Como Wiz descobriu o AttachMe
Ao construir o conector OCI para Wiz, nossos engenheiros de software perceberam que era possível anexar quase todos os volumes de blocos e volumes de inicialização a uma instância de computação, dado o Oracle Cloud Identifier (OCID), sem autorização explícita. Após mais testes, percebemos que isso era possível até mesmo quando o volume e a instância de computação residiam em diferentes locações da OCI! Isso significava que um invasor poderia obter acesso a um volume em outro locatário (desde que conhecesse o OCID), e quem fosse o proprietário do volume (a vítima) não saberia totalmente que outra pessoa tinha acesso de leitura/gravação aos seus dados, pois a instância de computação e o anexo estariam na locação do invasor.
Histórico – o que são volumes em OCI?
Conforme descrito na documentação da OCI, um volume é um disco virtual que fornece espaço de armazenamento persistente para instâncias de computação. Existem dois tipos de volumes em OCI:
• Volume em bloco — Um dispositivo de armazenamento em bloco destacável que permite expandir dinamicamente a capacidade de armazenamento de uma instância.
• Volume de inicialização — Um dispositivo de volume de inicialização destacável que contém a imagem usada para inicializar uma instância de computação e geralmente é criado na criação da instância de computação.
O OCI suporta multi-anexação de volumes de blocos, o que significa que você pode anexar um único volume a várias instâncias ao mesmo tempo usando o recurso compartilhável com permissões de leitura/gravação ou somente leitura.
Anexar um volume de inicialização ou bloco a uma instância de computação da CLI é simples, exigindo apenas os IDs de volume e instância:
oci compute volume-attachment attach --type paravirtualized --instance-id <instance_ocid> --volume-id <volume_ocid>
Com base na referência de política, as permissões necessárias para AttachVolume são VOLUME_WRITE, VOLUME_ATTACHMENT_CREATE e INSTANCE_ATTACH_VOLUME. A instância e o volume não precisam necessariamente estar no mesmo compartimento.
Anexo de volume é um recurso OCI que reside no compartimento da instância de computação e descreve um anexo de um volume a uma instância de computação. As permissões são aplicadas a um compartimento (e sua árvore de compartimentos). Portanto, VOLUME_ATTACHMENT_CREATE e INSTANCE_ATTACH_VOLUME são necessários no escopo do compartimento da instância (neste caso, o compartimento do invasor) e VOLUME_WRITE é necessário no escopo do compartimento do volume (o compartimento da vítima).
No entanto, conforme descobrimos, houve uma lacuna na validação da permissão VOLUME_WRITE ao anexar um volume, o que possibilitou anexar qualquer volume sem autorização. Além disso, a anexação era possível em diferentes locações: conseguimos anexar um volume de uma locação a uma instância de computação em outra locação.
Demonstração
Quando um usuário não autorizado tenta realizar qualquer operação em um volume, o serviço (corretamente) retorna um erro indicando que o usuário não possui as permissões necessárias:
elad_gabay@cloudshell:~ (us-ashburn-1)$ oci bv volume get --volume-id ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn*******************************************
ServiceError:
{
"client_version": "Oracle-PythonSDK/2.69.0, Oracle-PythonCLI/3.10.0",
"code": "NotAuthorizedOrNotFound",
"logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
"message": "Authorization failed or requested resource not found.",
"opc-request-id": "DFB9SCC25*****",
"operation_name": "get_volume",
"request_endpoint": "GET https://iaas.us-ashburn-oraclecloud.com/20160918/volumes/ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn*******************************************",
"status": 404,
"target_service": "blockstorage",
"timestamp": "2022-06-07114:12:21.408280",
"troubleshooting_tips": "See https://docs.oracle.com/iaas/Content/API/References/apierrors.htm#apierrors_404_404_notauthorizedornotfound for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
}
Legenda: Tentando acessar um volume usando a CLI sem permissões suficientes
No entanto, antes da correção de #AttachMe, a tentativa de anexar um volume a uma instância de computação era bem-sucedida, independentemente de o usuário ter permissões suficientes ou não:
elad_gabay@cloudshell:~(us-ashburn-1)$ oci compute volume-attachment attach --instance-id ocid1.instance.oc1.iad.anuwcljrixjtluica******************************************* --volume-id ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn3******************************************* --type paravirtualized
{
"data": {
"attachment-type": "paravirtualized",
"availability-domain": "zSfH:US-ASHBURN-AD-1",
"compartment-id": "ocid1.tenancy.oc1..aaaaaaaaote2dzazv**********************",
"device": "null",
"display-name": "volumeattachment20220607141228",
"id": "ocid1.volumeattachment.oc1.iad.anuwcljrixjtluic***********************",
"instance-id": "ocid1.instance-oc1.iad.anuwcljrixjtluica*********************",
"is-multipath": null,
"is-pv-encryption-in-transit-enabled":false,
"is-read-only":false,
"is-shareable": false,
"iscsi-login-state": null,
"lifecycle-state": "ATTACHING",
"time-created": "2022-06-07T14:12:29.027000+00:00",
"volume-id": "ocid1.bootvolume.oc1.iad.abuwcljrybvvdsn3***********************",
},
"etag": "992e06ff86b86a5fe732308092a55***********************************"
}
Legenda: Anexando com sucesso o mesmo volume que não tínhamos permissão para acessar
Uma vez que o volume foi anexado, pudemos visualizar e modificar seu conteúdo.
Os requisitos detalhados para explorar #AttachMe foram:
• O invasor deve conhecer o OCID do volume de destino — embora os OCIDs geralmente sejam privados, eles não são tratados como segredos, portanto, isso é facilmente alcançado.
• A instância de computação do invasor deve estar no mesmo Domínio de Disponibilidade (AD) que o volume de destino — essa condição pode ser facilmente atendida, pois o número de zonas de disponibilidade é relativamente pequeno (até três em algumas regiões) e, portanto, pode ser enumerado.
• O volume de destino deve ser desanexado ou anexado como compartilhável — os volumes desanexados são relativamente comuns porque, por padrão, os volumes de inicialização associados às instâncias de computação encerradas não são excluídos. Além disso, os volumes de dados de backup geralmente não são anexados a uma instância de computação em execução.
Análise de risco
Quando um invasor obtém acesso de leitura aos seus volumes, o principal risco é a violação de dados. Os volumes podem conter informações confidenciais, como informações de identificação pessoal (PII), segredos e muito mais.
Outro risco é a manipulação de dados e a intrusão em sua rede em nuvem. Anexar um volume fornece acesso de gravação que pode ser usado para manipular quaisquer dados no volume, incluindo o tempo de execução do sistema operacional (modificando binários, por exemplo), obtendo assim a execução de código sobre a instância de computação remota e um ponto de apoio no ambiente de nuvem da vítima, uma vez que o volume é usado para inicializar uma máquina.
Os caminhos de ataque potenciais incluem:
• Escalação de privilégios no compartimento ou na locação — se um invasor conseguisse obter acesso inicial ao ambiente OCI de uma vítima, #AttachMe poderia ter sido explorado para aumentar ainda mais os privilégios. Um invasor poderia consultar todos os volumes disponíveis no compartimento para obter seus OCIDs, montá-los e ler quaisquer informações confidenciais armazenadas neles.
• Acesso entre locatários — Um cenário mais impactante é se um invasor conseguir obter OCIDs de volumes em um locatário remoto. #AttachMe poderia ter sido usado para obter acesso inicial ao ambiente da vítima lendo informações confidenciais e segredos duradouros que foram armazenados nos volumes de destino. Além disso, o invasor pode ter manipulado volumes de blocos e volumes de inicialização existentes de uma maneira que fornecesse a execução do código do invasor quando os volumes fossem montados em instâncias de computação.
Consideramos os dois possíveis caminhos de ataque bastante viáveis, uma vez que os OCIDs geralmente não são tratados como segredos. Numerosos OCIDs de volumes de blocos e volumes de inicialização de vários ambientes, incluindo os de grandes empresas, podem ser encontrados por meio de uma simples pesquisa online.
Também é possível encontrar OCIDs de volumes que foram publicados no GitHub, indicando que esses IDs de fato não são tratados como segredos pelos desenvolvedores. Usuários com poucos privilégios e fornecedores terceirizados com acesso de leitura ao ambiente podem obter OCIDs com muita facilidade.
Cronograma de descoberta e divulgação
Ao descobrir o #AttachMe, divulgamos imediatamente nossas descobertas à Oracle, que investigou e corrigiu esse problema em menos de 24 horas. Ficamos felizes em colaborar com uma equipe tão profissional.
• 6 de junho de 2022 – Wiz descobre a vulnerabilidade
• 9 de junho de 2022 – Vulnerabilidade relatada à Oracle
• 10 de junho de 2022—A Oracle reconhece o relatório
• 10 de junho de 2022—A vulnerabilidade foi corrigida
Lições para construtores de nuvem e defensores de nuvem
A validação insuficiente das permissões do usuário é uma classe de bug comum entre os provedores de serviços em nuvem. A melhor maneira de identificar esses problemas é realizando revisões de código rigorosas e testes abrangentes para cada API sensível no estágio de desenvolvimento. A Oracle compartilhou conosco que eles usam a tecnologia de análise de código estático para detectar esses problemas já em desenvolvimento e investigar problemas conhecidos e relatados para garantir que o padrão problemático não se repita em outro lugar na base de código.
Também recomendamos realizar testes de penetração específicos do serviço e participar de programas de recompensa de bugs, pois eles se mostraram eficazes com esses tipos de problemas.
Rastreando vulnerabilidades na nuvem
AttachMe é a mais recente de uma longa linha de vulnerabilidades de isolamento de nuvem descobertas pela comunidade de pesquisa: exemplos recentes incluem “ExtraReplica” — uma vulnerabilidade de banco de dados entre locatários no Azure PostgreSQL também descoberta pela pesquisa Wiz e uma vulnerabilidade entre locatários no Azure Cloud Shell descoberto por Chen Cohen da equipe de testes de caneta do eBay.
Hoje, não há um processo claro em torno das vulnerabilidades da nuvem impostas pela comunidade de segurança. As vulnerabilidades da nuvem normalmente não são CVEs emitidas, portanto, são muito difíceis de serem rastreadas pelos clientes. Recentemente, pesquisadores da Wiz, juntamente com outros membros da comunidade de segurança na nuvem, iniciaram o Open Cloud Vulnerability & Security Issue Database para ajudar os usuários e defensores da nuvem a monitorar e rastrear vulnerabilidades na nuvem. Se você estiver interessado em contribuir, confira o GitHub do OpenCVDB.
Fonte: www.wiz.io
Posts relacionados: Microsoft Patch: 64 novas vulnerabilidades, incluindo cinco críticas / CISA – 5 vulnerabilidades do servidor Apache HTTP que afetam produtos Cisco e Patch de correção do Log4J 0-day possui vulnerabilidade explorável