Como ocorreu o vazamento de dados da Optus e como evitá-lo?

1. Introdução#

Em setembro de 2022, a Optus, uma das principais provedoras de telecomunicações da Austrália, sofreu um vazamento de dados que expôs as informações pessoais de quase 10 milhões de clientes. Este incidente marcou um dos maiores ataques cibernéticos da história da Austrália, gerando grandes preocupações em relação às práticas de privacidade e segurança de dados no país.

Este artigo focará nas seguintes questões:

• Quais falhas de segurança a Optus tinha que levaram ao vazamento de dados?
• Quais são alguns métodos de contramedida que a Optus poderia ter usado para evitar a violação de segurança?

2. Falhas de segurança que levaram ao vazamento de dados da Optus#

A seguir, você encontrará as 5 falhas de segurança do vazamento de dados na Optus.

2.1 Falha de segurança #1: API voltada para o público exposta#

A primeira grande falha de segurança no vazamento da Optus foi o uso de uma API (Interface de Programação de Aplicações) voltada para o público que facilitou o acesso a dados internos sensíveis. APIs públicas são projetadas para permitir que sistemas externos interajam com os serviços de uma empresa, mas quando essas APIs não são adequadamente protegidas, elas podem se tornar uma porta de entrada para invasores.

Para que são usadas as APIs públicas?

APIs públicas seguras, como, por exemplo, a API do Google Maps ou a API de clima, fornecem dados limitados e não sensíveis para sistemas externos. Elas são projetadas para isolar quaisquer dados compartilhados das operações centrais dos negócios, tornando-as inerentemente mais seguras.

Por que as APIs públicas são um problema neste caso?

Diferente das APIs seguras, a API da Optus expunha informações sensíveis de clientes e carecia de salvaguardas essenciais. Isso a tornou vulnerável a invasores que poderiam localizá-la por meio de varreduras na internet.

Como os invasores poderiam explorar essa API?

Sem autenticação ou isolamento de dados, os invasores podiam se conectar diretamente à API e recuperar informações confidenciais de clientes, contornando as medidas de segurança internas.

2.2 Falha de segurança #2: API não segura concedendo acesso a dados sensíveis de clientes#

A segunda grande falha de segurança no vazamento de dados da Optus foi que a API não era segura. Portanto, ela concedia acesso a dados de clientes altamente sensíveis. Enquanto o primeiro problema girava em torno da API ser voltada para o público, o problema crítico aqui foi a falta de controles de acesso adequados, o que permitiu o acesso irrestrito a informações confidenciais.

Quando um cliente da Optus acessa sua conta por meio do aplicativo móvel ou site da Optus, as APIs facilitam a comunicação entre os sistemas de frontend e backend para recuperar os dados necessários. Esses processos de backend geralmente lidam com informações sensíveis para carregar os perfis dos clientes.

Neste caso, a API exposta forneceu aos invasores acesso direto aos seguintes tipos de dados pessoais, que são particularmente valiosos para roubo de identidade e fraude:

• Números da carteira de motorista
• Números de telefone
• Datas de nascimento
• Endereços residenciais

Uma análise dos registros públicos do Sistema de Nomes de Domínio (DNS) revelou mais tarde que essa API provavelmente estava voltada para o público e acessível a qualquer pessoa na internet por até três meses.

2.3 Falha de segurança #3: Uso de identificadores de cliente incrementais#

A terceira falha de segurança no vazamento de dados da Optus foi o uso de identificadores de cliente incrementais. No mundo digital, identificadores de clientes únicos — compostos por sequências aleatórias de números e letras — são usados para diferenciar contas de forma segura. As melhores práticas de segurança cibernética ditam que esses identificadores devem ser aleatórios e não relacionados, para evitar que hackers identifiquem padrões.

Identificador de cliente da Optus: Neste caso, os identificadores de clientes seguiam um padrão previsível, diferindo por um incremento de 1. Por exemplo, se o identificador de um cliente era 5332, o próximo seria 5333. Uma vez que o hacker obteve acesso ao banco de dados, ele pôde escrever um script automatizado para recuperar cada registro simplesmente incrementando o identificador.

Essa abordagem automatizada acelerou o processo de roubo de dados, permitindo que o invasor exfiltrasse dados sensíveis de clientes em escala. A falha de design previsível permitiu que o vazamento da Optus ocorresse mais rapidamente e afetasse mais clientes do que seria possível de outra forma.

2.4 Falha de segurança #4: Controles de acesso enfraquecidos devido a um erro de código#

Além das vulnerabilidades de API e ID de cliente, havia mais problemas de segurança: Em 2018, um erro de código enfraqueceu os controles de acesso em certos domínios da Optus, tornando-os menos seguros. Embora a Optus tenha corrigido esse problema em seu site principal em agosto de 2021, não aplicou a mesma correção a um site secundário que era acessível na internet. Este domínio secundário permaneceu vulnerável até que o vazamento foi descoberto em setembro de 2022.

Essa omissão deixou uma lacuna de segurança significativa. Domínios voltados para o público são um alvo comum para invasores, e qualquer falha não corrigida aumenta o risco de acesso não autorizado. Neste caso, o erro de código tornou possível para os invasores contornarem os controles de acesso e acessarem dados sensíveis.

Ignorar domínios secundários ou menos visíveis pode deixar vulnerabilidades críticas abertas, que invasores podem explorar com facilidade. Auditorias regulares e testes minuciosos são essenciais para garantir que as atualizações de segurança sejam aplicadas em todos os lugares necessários.

2.5 Falha de segurança #5: Segundo domínio vulnerável#

Essa falta de supervisão adequada estendeu-se ao domínio secundário, que desempenhou um papel fundamental no vazamento. Embora o domínio não estivesse ativamente em uso, ele permaneceu online e desprotegido por um longo período. Apesar de ser desnecessário para as operações diárias, ele não foi protegido com controles de acesso adequados nem desativado, criando um ponto de entrada fácil para invasores explorarem.

Mesmo quando não estão em uso ativo, tais domínios ainda podem servir como vetores de ataque se existirem vulnerabilidades. Para mitigar esses riscos, as empresas devem auditar regularmente seus ativos digitais, desativar prontamente domínios não utilizados ou aplicar o mesmo nível de segurança dos sistemas ativos.

3. Como evitar tais vazamentos de dados?#

Para evitar vazamentos de dados semelhantes ao ataque à Optus e mitigar o risco de danos à reputação, as organizações podem adotar diferentes estratégias de segurança que você pode encontrar a seguir:

3.1 Contramedida #1: Consultar o OWASP API Security Project#

O OWASP API Security Project é um recurso atualizado regularmente que destaca riscos conhecidos de segurança de API. É essencial que as equipes de segurança cibernética monitorem rotineiramente este banco de dados para identificar e corrigir vulnerabilidades que possam impactar seus negócios. Ele abrange uma ampla gama de riscos potenciais, por exemplo:

• Autorização em Nível de Objeto Quebrada (BOLA): Lacunas nas permissões de acesso de usuários permitindo acesso não autorizado a dados.

• Exposição Excessiva de Dados: APIs que retornam mais informações do que o necessário, aumentando o risco de vazamentos de dados sensíveis.

• Configurações de Segurança Incorretas: Configurações desalinhadas ou padrões que expõem APIs sensíveis a ataques.

• Falhas de Injeção: Invasores que exploram APIs para injetar comandos ou dados maliciosos.

3.2 Contramedida #2: Proteger todas as APIs com um protocolo de autenticação#

O OWASP API Security Project destaca APIs não autenticadas como a segunda vulnerabilidade de API mais comum. Essas APIs não exigem um nome de usuário, senha ou qualquer outro método de autenticação para estabelecer uma conexão, deixando-as altamente vulneráveis à exploração. Esse tipo de fraqueza desempenhou um papel central no vazamento de dados da Optus.

Em alguns casos, as APIs são intencionalmente deixadas sem autenticação para manter a compatibilidade com sistemas legados ou para fins de teste. É provável que a Optus tenha deixado sua API não autenticada por razões semelhantes. No entanto, por mais críticos que possam ser os testes ou os requisitos do sistema legado, implantar qualquer API — seja interna ou pública — sem autenticação é um risco de segurança significativo.

Como evitar a exploração de API não autenticada

Para proteger suas APIs, cada solicitação de conexão deve ser garantida com Autenticação Multifator (MFA). A MFA adiciona uma camada adicional de proteção exigindo várias formas de verificação, tornando-se uma das maneiras mais eficazes e diretas de bloquear o acesso não autorizado a APIs e contas de usuários.

Identificando vulnerabilidades de API ocultas

Uma política de segurança de API só é eficaz se todas as APIs que exigem proteção forem contabilizadas. Mas o que acontece se sua organização for inadvertidamente exposta por uma API pública, como foi o caso da Optus?

APIs ocultas ou ignoradas são difíceis de detectar usando ferramentas de varredura padrão. A maneira mais eficaz de descobri-las é por meio de testes de invasão para expor vulnerabilidades como:

• Mecanismos de autenticação fracos: Sistemas que aceitam senhas em texto simples ou credenciais mal feitas.

• Exposição a credential stuffing ou ataques de força bruta: Explorar nomes de usuário e senhas roubados em escala.

• Manipulação de parâmetros de API: Revelar detalhes de autenticação sensíveis em URLs ou respostas.

4. Conclusão#

Em conclusão, o vazamento de dados da Optus ressalta a importância crítica de implementar medidas de segurança cibernética robustas e auditar regularmente os ativos digitais. A falha em proteger APIs, aplicar protocolos de autenticação adequados e lidar com vulnerabilidades ignoradas em domínios secundários contribuiu significativamente para esse incidente. Ao adotar as melhores práticas do setor, como aquelas descritas no OWASP API Security Project, e priorizar estratégias de segurança abrangentes, as organizações podem se proteger contra vazamentos semelhantes, proteger dados sensíveis de clientes e, o mais importante, manter a confiança de seus usuários.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

Perguntas Frequentes#

Quais dados pessoais foram roubados no vazamento da Optus e por que isso é tão prejudicial?#

A API exposta deu aos invasores acesso direto a números de carteira de motorista, números de telefone, datas de nascimento e endereços residenciais. Esses tipos de dados são especialmente valiosos para roubo de identidade e fraude, tornando o vazamento particularmente prejudicial para os clientes afetados.

Por que uma empresa deixaria uma API não autenticada em primeiro lugar?#

Às vezes, as APIs são intencionalmente deixadas não autenticadas para manter a compatibilidade com sistemas legados ou para fins de teste, o que provavelmente foi o caso da Optus. No entanto, implantar qualquer API, seja interna ou voltada para o público, sem autenticação é um risco de segurança significativo, independentemente da justificativa operacional.

Como as equipes de segurança podem descobrir APIs ocultas ou ignoradas antes que os invasores as explorem?#

Ferramentas de varredura padrão lutam para detectar APIs ocultas ou ignoradas. A abordagem mais eficaz são os testes de invasão, que podem expor mecanismos de autenticação fracos, exposição a ataques de credential stuffing e detalhes de autenticação sensíveis revelados em URLs ou respostas de API.

O que é o OWASP API Security Project e como ele ajuda as organizações a evitar vazamentos como o da Optus?#

O OWASP API Security Project é um recurso atualizado regularmente que cataloga riscos conhecidos de segurança de API, como Autorização em Nível de Objeto Quebrada, Exposição Excessiva de Dados, Configurações de Segurança Incorretas e Falhas de Injeção. As equipes de segurança cibernética devem monitorá-lo rotineiramente para identificar e corrigir vulnerabilidades antes que os invasores possam explorá-las.