No paradigma moderno da segurança da informação para as massas, a crença de que a segurança cibernética é cara, difícil e praticamente impossível para o usuário comum foi firmemente estabelecida. Portanto, se você deseja proteger totalmente seus dados e informações pessoais, crie uma conta no Google ou Amazon, identifique-a em termos de identificação do proprietário e verifique periodicamente os alertas de alarme de que uma empresa grande e forte interrompeu outra tentativa de login.
Mas as pessoas com conhecimento em segurança da informação sempre souberam: os serviços em nuvem são muito mais vulneráveis do que uma estação de trabalho separada. De fato, no caso de uma situação de força maior, o PC pode restringir fisicamente o acesso à rede, e aí a corrida já começa a mudar as aparências e senhas em todas as áreas atacadas. A infraestrutura de nuvem é enorme, geralmente descentralizada, e os dados de vários clientes podem ser armazenados no mesmo meio físico, ou vice-versa, os dados de um cliente estão espalhados pelos cinco continentes e apenas uma conta os combina.
Em suma, quando a Internet era relativamente nova e jovem (e era em 2003), os especialistas em segurança da informação analisaram cuidadosamente
o sistema de proteção contra transbordamento de buffer de 1997 e surgiram na tecnologia, que agora chamamos de
Honeytoken ou Canarytoken. E há quinze anos que eles estão funcionando adequadamente (e ainda funcionam), apenas as pesquisas mais recentes dizem que, em vez da última linha de defesa em vários serviços da AWS, a Honeytoken se transformou em um buraco na segurança da informação devido às peculiaridades da implementação no lado da Amazônia.
O que é Honeytoken
A Honeytoken, como seu progenitor ideológico no sistema de proteção contra transbordamento de pilhas, usa a abordagem "avisar, não impedir". De fato, o Honeytoken é uma isca para atacantes, que é deixada sob o disfarce de informações valiosas e pode ser apresentada na forma, por exemplo, de um link. O Honeytoken mais óbvio na prática de usuários comuns é um alarme de link, oculto em uma carta com o cabeçalho "informações da conta bancária" ou "minhas contas". O princípio também é simples: assim que um invasor examina as informações que a Honeytoken pretende ser, ele envia um alerta ao proprietário / administrador de que o perímetro de segurança foi violado.
Obviamente, o Honeytoken não está incluído no perímetro: na sua forma clássica, é um manequim banal que já está dentro do perímetro e desempenha o mesmo papel que os canários que morrem em gaiolas jogados nas faces de mineração - um aviso sobre o perigo.
E aqui está o progenitor da tecnologiaAgora, esses "sistemas de sinalização" são bastante comuns e são usados para alertar os titulares de contas pessoais para alertar sobre violações de segurança da AWS. Ao mesmo tempo, não existe um padrão Honeytoken único - pode ser qualquer coisa. Por exemplo, várias caixas de correio mortas especiais são adicionadas às listas de endereços de email dos clientes, a aparência de uma lista de correspondência na qual indicará a descarga de todo o banco de dados.
Qual é a vulnerabilidade encontrada na AWS?
O Amazon Web Services usa ativamente o sistema Honeytokens para receber alertas de alerta de nuvem de perímetro de serviço. As Amazon Canaries são chaves de acesso falsas à conta. Essa ferramenta, com toda a sua simplicidade, é extremamente importante: os serviços em nuvem estão sujeitos a constantes tentativas de hackers e outros ataques. O próprio fato de ter conhecimento sobre o "avanço" do perímetro de segurança cibernética da AWS em uma das direções já é metade da vitória para os engenheiros da Amazon.
Ontem, 2 de outubro de 2018, especialistas do Rhino Security Labs
publicaram um estudo extremamente desagradável, cuja essência é expressa pela seguinte declaração: Honeytokens Amazon Web Services pode ser contornado sem perturbar o sistema de sinalização em nuvem. Isso dá aos invasores a oportunidade de "entrar" silenciosamente, "pegar" o que precisam e também "sair" silenciosamente.
Toda a arquitetura do Honeytokes AWS é baseada no uso de chaves falsas em conjunto com o
CloudTrail , que também mantém registros de atividades. Mas disponível gratuitamente no Amazon do guia do usuário, existe uma lista completa de endereços e serviços que não oferecem suporte ao CloudTrail. De fato, isso significa que quaisquer solicitações para esses serviços, inclusive por meio da API, não são registradas em nenhum lugar. Ao mesmo tempo, a Amazon retorna as mensagens de retorno com um erro de acesso junto com o
ARN .
Em seguida, os pesquisadores da Rhino Security "
copiaram " o
AWS AppStream por meio
da API DescribeFleets e receberam as seguintes informações sobre a conta de teste:
Em seguida, com sua ajuda, um invasor extrai informações sobre o usuário / função do
IAM do seguinte plano:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName
IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionNameComo resultado, graças ao retorno do ARN e aos dados de usuário / função do IAM recebidos, os especialistas conseguiram comprometer as chaves de isca da Honeytokes nos serviços acima através da análise.
Contramedidas
O caminho encontrado coloca
em risco não apenas a AWS, mas também os desenvolvedores de sistemas populares de honeytoken para sistemas Amazon, como
CanaryToken e
SpaceCrab . Ambos os desenvolvedores foram notificados e estão tomando todas as medidas possíveis para resolver o problema.
Além disso, especialistas da Rhino Security
publicaram um script PoC
no GitHub que verificará se a chave da AWS fornecida é um token, pois nem todas as configurações foram atualizadas ainda.
Reação amazônica
A Amazon informou ao Rhino Security Labs que o ARN não é uma informação confidencial, o CloudTrain funciona (e não funciona) quando necessário, e não há nenhum problema como tal.