Falhas em subdomínios da Amazon permitiam ações indevidas em contas Alexa

Cadeia combinava configuração incorreta de CORS, XSS e exposição de token CSRF para instalar ou remover skills, acessar histórico de voz e consultar dados de perfil após um clique em link preparado.

Componente	Subdomínios Amazon/Alexa usados por APIs da aplicação Alexa, incluindo fluxos de consulta e gerenciamento de skills.
Vetor	Um usuário autenticado precisava clicar em um link da Amazon especialmente preparado; a exploração dependia de injeção de código em um subdomínio Amazon e de política CORS permissiva entre subdomínios.
Impacto	A cadeia podia permitir leitura de lista de skills, remoção e instalação de skills na conta da vítima, acesso ao histórico de comandos de voz e consulta de informações pessoais do perfil, sem envolver credenciais bancárias registradas pela Amazon.
Prioridade	Validar que correções de CORS, tratamento de erros, cabeçalhos de resposta e exposição de token CSRF estejam aplicadas; revisar telemetria de instalação e remoção de skills em contas afetadas.
Artefatos	Falhas associadas a CORS mal configurado, Cross-Site Scripting, token CSRF em resposta de API, parâmetro pageSize e chamadas envolvendo track[.]amazon[.]com e skillsstore[.]amazon[.]com.
Mitigação	A Amazon recebeu o relato em junho de 2020 e corrigiu o problema; a resposta defensiva deve incluir revisão de skills, histórico de voz, políticas de origem e fluxos de autenticação de APIs.

Resumo técnico

A vulnerabilidade descrita envolvia uma cadeia de falhas em serviços web usados pelo ecossistema Alexa, combinando uma política de Cross-Origin Resource Sharing permissiva com uma condição de Cross-Site Scripting e exposição de token CSRF em respostas de API. O resultado prático era a possibilidade de realizar ações em uma conta Alexa autenticada quando a vítima acessasse um link da Amazon preparado pelo atacante. A cadeia não exigia que o usuário digitasse credenciais em uma página falsa; a condição relevante era a sessão válida e o processamento indevido de requisições entre subdomínios Amazon/Alexa.

O ponto sensível do caso é que a Alexa atua como camada de controle para automação residencial e para skills de terceiros. Uma skill adicionada ou substituída indevidamente pode alterar a experiência de interação do usuário, capturar respostas fornecidas durante uma conversa com a skill e influenciar comandos por frase de invocação. A exploração também podia expor histórico de voz e respostas da assistente, além de dados de perfil, como endereço residencial e outras informações associadas à conta. O contexto não sustenta roubo de credenciais bancárias, e a própria descrição limita esse ponto: interações com skills bancárias poderiam revelar histórico ou dados informados na conversa, mas não senhas de login bancário gravadas pela Amazon.

A falha foi reportada à Amazon em junho de 2020 e posteriormente corrigida. Ainda assim, o caso é tecnicamente relevante porque mostra como vulnerabilidades web clássicas, quando aparecem em superfícies de identidade e automação doméstica, podem ultrapassar o impacto usual de uma aplicação isolada. A combinação de CORS, XSS e CSRF em APIs autenticadas cria uma ponte entre navegação web, permissões de conta e controle de funcionalidades conectadas a dispositivos de casa inteligente.

Fluxo técnico

A análise começou pelo tráfego da aplicação móvel Alexa, que implementava mecanismo de fixação de certificado TLS. Após contornar essa proteção para fins de inspeção defensiva em laboratório, foi possível observar requisições realizadas pela aplicação e identificar endpoints com política CORS mal configurada. A consequência técnica era que requisições Ajax poderiam ser aceitas a partir de outros subdomínios Amazon, abrindo espaço para abuso caso o atacante tivesse capacidade de injetar código em um desses subdomínios.

Uma das respostas de API retornava a lista de skills instaladas na conta Alexa e incluía também um token CSRF. Esse detalhe era crítico porque o token podia ser reutilizado para acionar ações autenticadas em nome da vítima. Em vez de depender apenas de uma falha isolada, a cadeia se apoiava no encadeamento de confiança indevida entre origem, sessão e token de proteção contra requisições forjadas. Com o token disponível e a política de origem permissiva, o atacante podia emitir chamadas para manipular skills associadas à conta.

A etapa de XSS surgia em uma requisição para track[.]amazon[.]com com os parâmetros paginationToken e pageSize. Ao alterar pageSize para um valor não numérico, o servidor produzia erro e refletia conteúdo de volta ao cliente. A resposta vinha com status 500 e tipo de conteúdo text/html, não application/json, o que permitia transformar o erro em execução de código no contexto afetado. Detalhes de PoC e comandos operacionais não são necessários para defesa e são omitidos; o ponto defensivo é que validação de tipo, codificação de saída e cabeçalho de resposta incorreto permitiram que um parâmetro de paginação virasse ponto de execução de script.

Com o código rodando no contexto explorável, a cadeia podia disparar requisições autenticadas para skillsstore[.]amazon[.]com usando a sessão da vítima. O fluxo demonstrado incluía consultar skills existentes, remover uma skill comum e instalar outra skill da loja com frase de invocação igual ou semelhante à removida. Quando o usuário tentasse usar a frase, a interação poderia ser direcionada para a skill escolhida pelo atacante. A instalação indevida não significa, por si só, que qualquer skill maliciosa passaria pela certificação da Amazon, pois há revisão e monitoramento de skills, mas a vulnerabilidade reduzia a barreira de controle da conta do usuário.

Superfície afetada

A superfície exposta era formada por contas Alexa autenticadas, APIs web usadas pela aplicação Alexa, subdomínios Amazon/Alexa com relação de confiança permissiva e o modelo de skills de terceiros. O usuário precisava interagir com um link preparado em domínio Amazon, e o atacante precisava de capacidade de injeção de código em um subdomínio aceito pela política CORS. Essa precondição diferencia o caso de uma exploração direta sem interação: a sessão da vítima e a confiança entre origens eram componentes necessários da cadeia.

As ações possíveis ficavam concentradas no escopo da conta Alexa e de seus recursos: listagem de skills instaladas, remoção de uma skill, instalação de uma skill disponível, leitura do histórico de voz e consulta de informações pessoais presentes no perfil. O impacto depende da conta, das skills instaladas e do tipo de interação registrada. Usuários que utilizavam Alexa para automação residencial, controle de ar-condicionado, iluminação, entretenimento, aspiradores e outros dispositivos IoT tinham maior exposição operacional porque a assistente funcionava como intermediária entre a conta e os dispositivos domésticos.

O risco também atingia a privacidade. O histórico de voz podia conter comandos e respostas da Alexa, inclusive interações com skills sensíveis. Em cenários com skills bancárias ou de serviços pessoais, a exposição descrita envolve dados de histórico ou informações declaradas durante a interação, não credenciais de autenticação bancária armazenadas pela plataforma. Essa distinção é importante para resposta a incidente: a revisão deve focar dados conversacionais, histórico, perfil e alterações em skills, sem presumir vazamento de senhas quando isso não estiver demonstrado.

• Contas Alexa com sessão ativa que acessassem link Amazon preparado pelo atacante.
• APIs que retornavam lista de skills e token CSRF em resposta acessível por requisições cruzadas.
• Endpoint com parâmetro pageSize capaz de gerar erro refletido com Content-Type inadequado.
• Ambientes domésticos em que Alexa controla dispositivos IoT por skills e comandos de voz.

Hunting e telemetria

A investigação defensiva deve priorizar eventos de conta e aplicação, não apenas alertas de endpoint. A exploração descrita dependia de mudanças em skills, consultas autenticadas e acesso ao histórico de voz. Em logs de aplicação, sinais relevantes incluem origens incomuns em chamadas CORS, requisições Ajax entre subdomínios que normalmente não deveriam interagir, respostas 500 associadas a parâmetros de paginação inválidos e respostas HTML em endpoints esperados como JSON.

No nível da conta Alexa, a caça deve procurar instalação de skills não reconhecidas, remoção inesperada de skills previamente usadas e substituição por skill com frase de invocação parecida. Esse padrão é relevante porque o fluxo demonstrado não precisava criar uma skill invisível; ele podia trocar a experiência do usuário por meio da remoção de uma skill legítima e instalação de outra disponível. A linha do tempo deve correlacionar clique em link, sessão web ativa, alteração de skills e consultas ao histórico de voz.

Equipes de segurança que monitoram aplicações web devem tratar esse caso como exemplo de cadeia entre controles que muitas vezes são avaliados separadamente. Um CORS permissivo pode parecer impacto limitado se analisado sozinho, e uma resposta de erro refletida pode parecer apenas XSS localizado. Quando a resposta também expõe token CSRF e o navegador carrega credenciais da vítima, a superfície passa a permitir ações autenticadas. Por isso, hunting deve combinar telemetria de origem HTTP, cabeçalhos, códigos de erro, chamadas de API sensíveis e mudanças de estado na conta.

• Requisições com origem cruzada vindas de subdomínios Amazon não esperados para APIs Alexa.
• Erros HTTP 500 relacionados a valores não numéricos em pageSize ou parâmetros de paginação.
• Respostas text/html em endpoints que deveriam responder como application/json.
• Consulta de lista de skills seguida de remoção e instalação em curto intervalo.
• Acesso ao histórico de voz próximo de alterações de skills ou de sessão web anômala.

Mitigação

A correção técnica central é restringir CORS a origens estritamente necessárias, bloquear credenciais em origens não autorizadas e impedir que um subdomínio menos confiável consiga acionar APIs sensíveis de outro subdomínio. APIs que retornam tokens CSRF não devem ficar expostas a chamadas cruzadas permissivas; além disso, tokens de proteção precisam ser vinculados ao fluxo esperado e validados junto com origem, método, sessão e finalidade da operação.

A condição de XSS exige validação rigorosa de entrada e codificação de saída, especialmente em parâmetros aparentemente simples, como tamanho de página e paginação. Quando um endpoint retorna JSON, erros também devem manter tipo de conteúdo e estrutura compatíveis com JSON, sem refletir valores controlados pelo usuário como HTML executável. A aplicação também deve aplicar cabeçalhos defensivos que reduzam execução indevida de script e separar domínios por níveis de confiança, evitando que uma falha em um subdomínio se transforme em controle de APIs de conta.

Para usuários e equipes responsáveis por contas e ambientes com Alexa, a resposta prática é revisar skills instaladas, verificar histórico de voz, procurar remoções ou instalações não reconhecidas e remover integrações que não sejam necessárias. Em ambientes corporativos, residências assistidas, laboratórios e espaços com automação sensível, a recomendação é tratar assistentes virtuais como ativos de identidade e controle, não apenas como dispositivos de conveniência. A revisão deve incluir permissões de skills, frases de invocação, histórico de comandos e contas vinculadas a serviços externos.

Como a Amazon corrigiu o problema após o relato, a validação pós-correção deve confirmar que a política CORS rejeita origens indevidas, que o token CSRF não é recuperável por fluxo cruzado, que alterações em skills exigem validações adequadas e que endpoints com erro não refletem entrada como HTML executável. O caso também reforça a necessidade de monitoramento contínuo de skills publicadas e de mudanças de comportamento em skills ativas, porque a cadeia de abuso explorava tanto a camada web quanto o modelo de extensões da assistente.

• Aplicar allowlist estrita de origens CORS e revisar uso de credenciais em chamadas cruzadas.
• Remover exposição de token CSRF em respostas acessíveis por origens não autorizadas.
• Validar parâmetros como pageSize e padronizar respostas de erro como JSON quando o endpoint for JSON.
• Revisar skills instaladas, frases de invocação e histórico de voz das contas Alexa.
• Correlacionar mudanças de skills com sessões web e eventos de acesso ao histórico.